Newsgroup: it.comp.www.php
Titolo: python o php

si dice che nella stesura di pagine web dinamiche, python sta prendendo 
sopravvento rispetto a php.
Php secondo voi sparirà?
 
Sto già iniziando a leggere qualcosa su questo python, ma non mi pare ad 
esempio sia così facile iniettare del codice python in un documento html.
 
In php basta fare
 
<html>
<?php ... ?>
</html>
 
ma con python?
 
Dicono che bisogna per forza usare un sistema di templating (far 
generare a python tutto il codice html).
 
Per il web quindi lo reputate giusto investire su python?

 Per il web quindi lo reputate giusto investire su python?
 
Fatta su i.c.w.php questa domanda che risposta vuoi che abbia? :)
 
A parte questo, Python personalmente come ha già detto varie volte non mi
piace per vari motivi, e per lo sviluppo web ce ne sono anche altri.
 
Ciao!

 Per il web quindi lo reputate giusto investire su python?
 
dipende da cosa devi farci con il "web" e soprattutto il tuo gusto 
personale.
 
In ambiente corporate difficilmente trovi roba fatta in un solo 
linguaggio, ma diversi moduli sviluppati con il linguaggio piu' adatto (o 
che per lo sviluppatore era il piu' adatto)
 
Comunque per python per il web guardati 'django' (non il film)
 
 
 
 
 
-- 
Jeff

 
 
Infatti quando m'hanno portato a vedere il film era proprio diverso da come
me l'aspettavo..
 
Ciao!


 
da qualche parte, non mi posso ricordare tutti i siti che visito :P
 
 

 Comunque per python per il web guardati 'django' (non il film)
 
praticamente un python adattato per web-apps

 Per il web quindi lo reputate giusto investire su python?
 
No.
 
Bye.

 Mi pare ci fosse un progetto per embeddare python nell'HTML ma non lo usa
 
In ogni caso, anche in php usare un sistema di templating puo' aiutare 
molto, soprattutto in caso di progetti medio/grandi.
 
Ciao.
 
ps. usare il php inline e' una porcheria...
 
-- 
Voglia di Gusto: prodotti senza glutine, per intolleranze e biologici
via Matteotti, 30/a - Cento (FE)
telefono: 051.412.3838
http://www.vogliadigusto.it
 
in...@vogliadigusto.it
 
 
** Per scrivermi in mail, sostituire nutella con ferrero...
** To contact me by email, change nutella to ferrero...

 
 
Semmai è il contrario, i motori di templating sono una porcata che usano
quelli che non sanno come lavorare in maniera pulita su una view.
 
M2C,
Ciao!

On Mon, 23 Feb 2015 22:05:21 +0100, alex scrisse:

framework, si dice framework
 
 
 
 
 
-- 
Jeff

On Tue, 24 Feb 2015 08:24:18 -0800, fmassei scrisse:

se poi vogliamo dirla tutta mvc e' una porcata per progetti grandi - 
diventa ingestibile se non tutti gli sviluppatori stanno attenti (e 
qvesto 
non succede mai)
 
 
 
 
 
-- 
Jeff


E quale alternativa più semplice consiglieresti? :)
E non mi dire MPC, PAC o altri nomi buffi per dire MVC de n'antra maniera :)
 
Ciao!

 framework, si dice framework
 
che serve ad agevolare l'implementazione online di python, o sbaglio?
 
 
 

 non succede mai)
 
E se non tutti sono competenti, e se non si rispettano regole di base 
comuni.
Più diventa grande un progetto e più devi mettere percorsi obbligati e 
far sviluppare su binari prefissati, altrimenti ognuno fa' quello che 
gli pare...
 

 Per il web quindi lo reputate giusto investire su python?
 
Assolutamente no.
PHP è fatto apposta per il web, python no, già questo mi pare un ottimo 
motivo per evitare di usare python sul web.


A me 'sto modo di pensare fa ribollire il sangue.. :(
 
1. Più "binari prefissati" metti più il tuo codice sarà pieno di hack per
aggirare i tuoi stessi paletti, senza contare le ore spese a pensarli e a
scriverli.
2. Se i tuoi programmatori non sono competenti non c'è da dire "bah, vabè,
non son competenti..". Non esiste il risparmio su una cosa del genere, che
dici prendo due a caso per strada e li metto a lavorare su un framework
completamente lock-ato, così tanto male non possono fare. Però puoi fare due
cose:
2a. falli studiare/ricercare/pagagli un corso o qualsiasi cosa per farli
diventare compententi. Ma figurati.
2b. cacciali e prendi dei programmatori competenti. Ma magari non li vuoi
pagare abbastanza.
3. Se non sei nella posizione di decidere nulla, hai semplicemente dei
colleghi incompetenti, perdi (molta) parte del tuo tempo ad insegnarli cose,
così che possano diventare produttivi, invece che un peso.
 
I pattern architetturali servono ad *agevolare* lo sviluppo, non a mettere
paletti.
 
Vabbè, smetto, che m'altero.
 
Ciao!


E non ti alterare che è meglio.
 
Per binari prefissati intendevo dire:
1) obbligarli a lavorare in un framework (sia nel senso di 
implementazione che in un senso lato), per fare in modo che:
2) siano "guidati" dai pattern architetturali pensati da chi ha scritto 
il framework
 
l'ideale secondo me è che chi ha più le mani in pasta si dedica al 
framework, chi è "meno competente" (vuoi perché ha studiato meno, vuoi 
perché è più giovane o meno esperto in generale) lavora dentro al 
framework, quindi è "guidato" da chi ha più competenze.
 
prendo sempre come esempio java, che è molto rigido ma, guardacaso, è 
anche molto utilizzato in ambito enterprise.
Al contrario python su certi aspetti e rigido, mentre su altri è 
paurosamente lassista e la sua implementazione della programmazione ad 
oggetti lascia molto a desiderare.
 
Per quanto riguarda le competenze e il loro sviluppo, fra il dire e il 
fare c'è di mezzo il mare, e un sacco di tempo e risorse che l'azienda 
deve investire. Se l'azienda non se lo può permettere (magari è una 
piccola azienda...) glielo paghi tu il corso, con il capo che ti guarda 
storto perchè "non-stai-producendo-e-in-più-ti-devo-pagare-il-corso"?


 
La piccola azienda decide se pagare poco un povero cristo ed avere un 
prodotto scadente o pagare un programmatore il giusto ed avere un prodotto
valido. Dipende dal suo modello di business.
 
Ciao!

 valido. Dipende dal suo modello di business.
 
Puoi anche avere un prodotto "valido" scritto in modo scadente da un 
programmatore scadente. Funziona, ma quando dovrai farci manutenzione 
sarà un inferno.
 
 

 sarà un inferno.
 
"un prodotto valido scritto in modo scadente da un programmatore scadente" - 
'sta cosa non esiste. Se è 'valido' secondo i miei standard è scritto bene, e
ci puoi fare sopra manutenzione senza problemi.
 
Ciao!

 ci puoi fare sopra manutenzione senza problemi.
 
Infatti valido era scritto tra virgolette. Sempre un prodotto scadente 
rimane per i motivi che tutti sappiamo, e il fatto che sia un accrocco 
incollato con lo scotch al committente spesso non interessa e 
l'importante è che funzioni, questo era il senso.
 

 <snip>
 
Ma infatti la mia non voleva essere l'inizio di una mostra di peni,
figuriamoci, voleva solo essere un modo per farti capire che quello che penso
lo penso non perché l'ho letto da qualche parte o me lo sono immaginato, ma
perché mi sono fatto delle opinioni personali durante gli anni.
 
Mi dispiace se la cosa suonava antipatica, non era mia assolutamente mia
intenzione.
 
Di tipi di framework, di team di sviluppo, di progetti, negli anni ne ho visti
a centinaia di tutti i tipi, e alla fine mi son fatto un'idea abbastanza
precisa di come dev'essere fatto un team, di come portare avanti un progetto
e cosa bisogna chiedere ad un framework. Evidentemente anche te hai le idee
tue, che ti sei fatto nella tua esperienza. Non ti dico di credere a quello
che dico, ma di prenderlo in considerazione, poi oh, ognuno c'ha le idee sue
e le cambia se e quando gli va.
 
Quello che non accetto, come ho detto sopra, è l'idea abbastanza diffusa che
esprimevi all'inizio, ovvero che un framework più restrittivo aiuta nello
sviluppo i programmatori meno esperti. Nella realtà non funziona così, e chi
si affida a questo modo di pensare ha la strada aperta verso un sacco di
grattacapi.
 
Ciao!

On Thu, 26 Feb 2015 18:33:11 +0100, marimbarza scrisse:

Ognuno deve essere libero di fare quello che gli pare, quello che intendo 
io e' che in MVC tutto diventa troppo complesso se l'applicazione e' 
enorme e per progetto web questo diventa sempre vero, view che modificano 
view, di, modelli che interagiscono con altri model e controller che 
vengono attivati da chissaquale view.
Si creano dipendenze che sono completamente ingestibili e impossibili da 
tracciare se non da chi le ha create e il tempo di creare documentazione 
chiara non c'e' mai in produzione.
 
 
-- 
Jeff

On Tue, 24 Feb 2015 08:37:05 -0800, fmassei scrisse:

Okey non avevo visto la risposta ed ho risposto ad un altro messaggio, 
ora noi in azienda stiamo muovendo tutto su FLUX e il backend PHP serve 
solo esclusivamente API REST(ful)
 
Quindi ogni chiamata dal frontend JS identifica sempre ed unicamente 1 
risorsa il PHP e' estremamente piu' chiaro. in pratica non ci sono view 
(l'output e' sempre oggetti json). 
 
Abbiamo 1 sola view che stampa e' il template per l'app JS.
 
Il lavoraccio e' fatto in Javascrip REACT+FLUX, e' stato confusissimo 
partire ma ora che abbiamo bene o male tutti chiaro il flusso 
dell'applicazione siamo molto piu' efficienti nello sviluppo e il flusso 
e la mappatura dell'app e' estremamente piu' semplice e chiaro e non 
esplode al crescere dell'app
 
 
 
-- 
Jeff

 
 
Che la documentazione non c'è e non ci sarà mai è chiaro a tutti fin dal
principio, su qualsiasi progetto, a qualsiasi livello ;)
 
Ciao!


Sì, boh, non so. Per alcuni tipi di siti/applicazioni è un'architettura che
ha senso, per altri no.
 
Come hai descritto per esempio non mi piace molto in generale perché hai
business logic in due linguaggi diversi, ma sempre meglio di un full-stack in
js tipo con nodejs o chissà che robe; ovviamente ci sono casi in cui invece
è la soluzione ideale.
 
Comunque, di sicuro una grossa applicazione FLUX (ne esistono?) di sicuro sarà
molto più incasinata di una "classica" in PHP ;)
 
Ciao!

 Ciao!
 
Questo non e' vero in assoluto. Non metto in dubbio che siamo piu' 
abituati a strutture php complesse (siamo dentro icwp dopo tutto) ma la 
chiarezza della nuova struttura e' oro
 
 
 
-- 
Jeff