Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > it.comp.www.php > #22112 > unrolled thread
| Started by | alex <1j9448a02@lnx159sneakemail.com.invalid> |
|---|---|
| First post | 2018-07-25 11:03 +0200 |
| Last post | 2018-08-06 07:17 +0000 |
| Articles | 20 on this page of 66 — 7 participants |
Back to article view | Back to it.comp.www.php
il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 11:03 +0200
Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-07-25 02:36 -0700
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 13:31 +0200
Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-07-25 05:50 -0700
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 17:13 +0200
Re: il ruolo di un validatore enrico bosi <rnsrico@bo.b> - 2018-07-25 17:48 +0200
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 17:59 +0200
Re: il ruolo di un validatore fmassei@gmail.com - 2018-07-25 09:53 -0700
Re: il ruolo di un validatore fmassei@gmail.com - 2018-07-25 08:22 -0700
Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-07-26 11:54 +0200
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-27 09:45 +0200
Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-07-27 10:22 +0100
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-27 12:39 +0200
Re: Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-07-28 13:01 +0200
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-29 11:22 +0200
Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-07-29 12:18 +0200
Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-03 07:40 -0700
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-04 09:40 +0200
Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-04 05:41 -0700
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-10 19:45 +0200
Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-08-27 11:43 +0200
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-30 11:21 +0200
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-01 08:26 +0200
Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-05 15:51 +0100
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-05 18:56 +0200
Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-05 21:30 +0200
Re: il ruolo di un validatore enrico bosi <rnsrico@bo.b> - 2018-08-06 16:33 +0200
Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-06 07:47 -0700
Re: il ruolo di un validatore enrico bosi <rnsrico@bo.b> - 2018-08-06 22:47 +0200
Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-06 14:59 -0700
[OT] Re: il ruolo di un validatore g4b0 <g4b0@nospam.com> - 2018-08-03 15:27 +0000
Re: [OT] Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-03 08:35 -0700
Re: [OT] Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-03 18:24 +0100
Re: [OT] Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-03 17:23 -0700
Re: [OT] Re: il ruolo di un validatore g4b0 <g4b0@nospam.com> - 2018-08-06 07:52 +0000
Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-06 10:22 +0100
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) fmassei@gmail.com - 2018-08-06 08:10 -0700
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-06 16:31 +0100
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) fmassei@gmail.com - 2018-08-06 08:39 -0700
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-06 18:03 +0100
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) fmassei@gmail.com - 2018-08-06 10:29 -0700
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-08 15:51 +0100
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 07:02 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-07 07:50 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-07 16:30 +0100
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-08 07:06 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-08 13:27 +0200
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-08 12:39 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-08 15:13 +0200
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-08 13:44 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-08 16:15 +0100
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 06:48 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-08 16:57 +0100
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 07:00 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-09 11:28 +0100
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 12:41 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-09 13:50 +0100
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 15:27 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 15:31 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-09 18:23 +0100
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-10 07:26 +0000
Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-10 10:27 +0100
Re: [OT] Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-08-03 23:04 -0700
Re: [OT] Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-05 16:24 +0100
Re: [OT] Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-08-05 09:59 -0700
Re: [OT] Re: il ruolo di un validatore g4b0 <g4b0@nospam.com> - 2018-08-06 07:17 +0000
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Umberto Salsi <salsi@icosaedro.it> |
|---|---|
| Date | 2018-08-27 11:43 +0200 |
| Message-ID | <pm0h65$1vcs$1@gioia.aioe.org> |
| In reply to | #22188 |
alex <1j9448a02@lnx159sneakemail.com.invalid> wrote:
> Il 29/07/2018 12:18, Umberto Salsi ha scritto:
> > try {
> > $res = $db->query($query);
> > }
> > catch(SQLException $e){
> >
> > // Log issue on server, with stack trace:
> > error_log("failed query: $query: $e");
> >
> > // User feedback:
> > ?>
> > Siamo spiacenti, ma si è verificato un problema nel nostro
> > sistema nel compiere quest'ultima operazione. Il personale
> > tecnico è stato già avvertito e sta lavorando alacremente per
> > risolverlo quando prima. Ti preghiamo di riprovare più tardi.
> > Grazie.
> > <?php
> > exit(0);
> > }
>
> Ma invece di invocare implicitamente il metodo __toString(), non sarebbe
> più giusto invocare il metodo __debugInfo() (tramite print_r($e, true))
> che è fatto apposta per restituire un array con i dati di debug?
>
Che differenza fa __debugInfo() con __toString()? A parte il fatto che
con __toString() puoi facilmente costruire stringhe composte, mentre
con __debugInfo() no.
Una volta definito il metodo magico __deugInfo(), come fai poi a sapere
cosa c'è *veramente* dentro a un oggetto? Gli strumenti di debugging
servono quando succedono cose inattese, per cui da var_dump() ti aspetti
di vedere cosa c'è veramente, non quello che il programmatore ha deciso
di mostrare. Usi la reflection?
Se poi ci aggiungi print_r, che stampa i dati in formato "human readable",
non capisci più nulla:
print_r(123)
print_r(123.0)
print_r("123")
stampano tutti la stessa cosa, così come
print_r("")
print_r(false)
print_r(null)
e non è una bella cosa ai fini diagnostici. Insomma, è da valutare,
ma dovresti argomentare.
Ciao,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it
[toc] | [prev] | [next] | [standalone]
| From | alex <1j9448a02@lnx159sneakemail.com.invalid> |
|---|---|
| Date | 2018-08-30 11:21 +0200 |
| Message-ID | <pm8cvb$qvp$2@gioia.aioe.org> |
| In reply to | #22205 |
Il 27/08/2018 11:43, Umberto Salsi ha scritto: > e non è una bella cosa ai fini diagnostici. Insomma, è da valutare, > ma dovresti argomentare. Valuterò :)
[toc] | [prev] | [next] | [standalone]
| From | alex <1j9448a02@lnx159sneakemail.com.invalid> |
|---|---|
| Date | 2018-08-01 08:26 +0200 |
| Message-ID | <pjrjpv$qbs$1@gioia.aioe.org> |
| In reply to | #22123 |
Il 27/07/2018 11:22, Alessandro Pellizzari ha scritto: > > Una funzione di filtraggio dovrebbe sempre tornare un valore usabile, o > lanciare un'eccezione in caso di errori. > > Una di validazione, in genere, dovrebbe tornare solo true o false. Differenze tra un filtro e un sanitizzer?
[toc] | [prev] | [next] | [standalone]
| From | Alessandro Pellizzari <shuriken@amiran.it> |
|---|---|
| Date | 2018-08-05 15:51 +0100 |
| Message-ID | <fsoh7lFp4mtU1@mid.individual.net> |
| In reply to | #22128 |
On 01/08/18 07:26, alex wrote: > Differenze tra un filtro e un sanitizzer? La differenza "ufficiale" la trovi qui: http://php.net/manual/en/filter.filters.php Un filtro è in generale qualcosa attraverso cui i dati vengono processati. Un validatore applicato al filtro torna il valore o un errore. Un sanitizer modifica il valore in modo che sia usabile da un sistema specifico (il browser, il DB, ecc.) Io mi sono fatto un mindset più funzionale negli ultimi anni: un filtro (filter in termini funzionali) fa passare un dato o meno. Un sanitizer (map) trasforma il valore. Possono essere combinati (filter_map) per far passare un valore e contemporaneamente trasformarlo, o bloccarlo del tutto. Bye.
[toc] | [prev] | [next] | [standalone]
| From | alex <1j9448a02@lnx159sneakemail.com.invalid> |
|---|---|
| Date | 2018-08-05 18:56 +0200 |
| Message-ID | <pk7ae3$1gml$1@gioia.aioe.org> |
| In reply to | #22137 |
Il 05/08/2018 16:51, Alessandro Pellizzari ha scritto: > On 01/08/18 07:26, alex wrote: > >> Differenze tra un filtro e un sanitizzer? > > La differenza "ufficiale" la trovi qui: > > http://php.net/manual/en/filter.filters.php > > Un filtro è in generale qualcosa attraverso cui i dati vengono processati. > > Un validatore applicato al filtro torna il valore o un errore. Semmai un fltro applicato a un validatore?
[toc] | [prev] | [next] | [standalone]
| From | alex <1j9448a02@lnx159sneakemail.com.invalid> |
|---|---|
| Date | 2018-08-05 21:30 +0200 |
| Message-ID | <pk7jg5$18u$1@gioia.aioe.org> |
| In reply to | #22140 |
Il 05/08/2018 18:56, alex ha scritto: > Il 05/08/2018 16:51, Alessandro Pellizzari ha scritto: >> On 01/08/18 07:26, alex wrote: >> >>> Differenze tra un filtro e un sanitizzer? >> >> La differenza "ufficiale" la trovi qui: >> >> http://php.net/manual/en/filter.filters.php >> >> Un filtro è in generale qualcosa attraverso cui i dati vengono >> processati. >> >> Un validatore applicato al filtro torna il valore o un errore. > > Semmai un fltro applicato a un validatore? Come non detto, fa caldo e ogni anno vado in avaria :)
[toc] | [prev] | [next] | [standalone]
| From | enrico bosi <rnsrico@bo.b> |
|---|---|
| Date | 2018-08-06 16:33 +0200 |
| Message-ID | <pk9mg0$1b5a$1@gioia.aioe.org> |
| In reply to | #22137 |
Il 05/08/2018 16:51, Alessandro Pellizzari ha scritto: > Io mi sono fatto un mindset più funzionale negli ultimi anni: un filtro > (filter in termini funzionali) fa passare un dato o meno. Un sanitizer Io lo chiamerei anche checker.
[toc] | [prev] | [next] | [standalone]
| From | fmassei@gmail.com |
|---|---|
| Date | 2018-08-06 07:47 -0700 |
| Message-ID | <35cd5c03-8628-4ab8-af09-c04012f62aed@googlegroups.com> |
| In reply to | #22146 |
On Monday, August 6, 2018 at 10:37:55 AM UTC-4, enrico bosi wrote: > Il 05/08/2018 16:51, Alessandro Pellizzari ha scritto: > > Io mi sono fatto un mindset più funzionale negli ultimi anni: un filtro > > (filter in termini funzionali) fa passare un dato o meno. Un sanitizer > > Io lo chiamerei anche checker. Un "checker" farebbe i "check", quindi non mi sembra un buon nome per un sanitizer. Ciao!
[toc] | [prev] | [next] | [standalone]
| From | enrico bosi <rnsrico@bo.b> |
|---|---|
| Date | 2018-08-06 22:47 +0200 |
| Message-ID | <pkaccd$j6b$1@gioia.aioe.org> |
| In reply to | #22147 |
Il 06/08/2018 16:47, fmassei@gmail.com ha scritto: > On Monday, August 6, 2018 at 10:37:55 AM UTC-4, enrico bosi wrote: >> Il 05/08/2018 16:51, Alessandro Pellizzari ha scritto: >>> Io mi sono fatto un mindset più funzionale negli ultimi anni: un filtro >>> (filter in termini funzionali) fa passare un dato o meno. Un sanitizer >> >> Io lo chiamerei anche checker. > > Un "checker" farebbe i "check", quindi non mi sembra un buon nome per un > sanitizer. > > > Ciao! > Mi riferivo al filtro non al sanitier.
[toc] | [prev] | [next] | [standalone]
| From | fmassei@gmail.com |
|---|---|
| Date | 2018-08-06 14:59 -0700 |
| Message-ID | <0e1b8f52-614a-4a0c-949a-a571073409b2@googlegroups.com> |
| In reply to | #22153 |
Peggio ancora :) Ciao!
[toc] | [prev] | [next] | [standalone]
| From | g4b0 <g4b0@nospam.com> |
|---|---|
| Date | 2018-08-03 15:27 +0000 |
| Subject | [OT] Re: il ruolo di un validatore |
| Message-ID | <pk1s9r$11rl$1@gioia.aioe.org> |
| In reply to | #22123 |
Il Fri, 27 Jul 2018 10:22:54 +0100, Alessandro Pellizzari ha scritto: > Tornare tipi diversi porta ad avere casini alla fine, ed è uno dei punti > più odiati di PHP (per esempio alcune funzioni tornano un oggetto se va > tutto bene, false se non hanno trovato la parte da modificare, null in > caso di errori. Puntualmente ci si dimentica di gestire uno dei casi. Quoto, soprattutto la parte che parla dei punti odiati. Provate a andare a parlate di PHP su i.l.i., vi massacrano a prescindere :D In parte hanno ragione, PHP dovrebbe darsi una rinfrescata, è vero che con PHP7 hanno migliorato molto, ma il linguaggio sta rimanendo indietro rispetto ai competitor. Voi che ne pensate? g4b0 P.S. Scusate l'OT, se il flame si accende apriamo un thread apposito =D
[toc] | [prev] | [next] | [standalone]
| From | fmassei@gmail.com |
|---|---|
| Date | 2018-08-03 08:35 -0700 |
| Subject | Re: [OT] Re: il ruolo di un validatore |
| Message-ID | <89ca3bba-4581-4571-9ecb-e727f79c123e@googlegroups.com> |
| In reply to | #22130 |
On Friday, August 3, 2018 at 11:27:58 AM UTC-4, g4b0 wrote: > Quoto, soprattutto la parte che parla dei punti odiati. Provate a andare > a parlate di PHP su i.l.i., vi massacrano a prescindere :D > > In parte hanno ragione, PHP dovrebbe darsi una rinfrescata, è vero che > con PHP7 hanno migliorato molto, ma il linguaggio sta rimanendo indietro > rispetto ai competitor. > > Voi che ne pensate? > PHP è un linguaggio orribile. Le alternative sono peggiori. Ciao!
[toc] | [prev] | [next] | [standalone]
| From | Alessandro Pellizzari <shuriken@amiran.it> |
|---|---|
| Date | 2018-08-03 18:24 +0100 |
| Subject | Re: [OT] Re: il ruolo di un validatore |
| Message-ID | <fsjhdjFlmhlU1@mid.individual.net> |
| In reply to | #22130 |
On 03/08/2018 16:27, g4b0 wrote: > Il Fri, 27 Jul 2018 10:22:54 +0100, Alessandro Pellizzari ha scritto: > Quoto, soprattutto la parte che parla dei punti odiati. Provate a andare > a parlate di PHP su i.l.i., vi massacrano a prescindere :D Haters gonna hate. :D > In parte hanno ragione, PHP dovrebbe darsi una rinfrescata, è vero che > con PHP7 hanno migliorato molto, ma il linguaggio sta rimanendo indietro > rispetto ai competitor. PHP ha un po' di rogne legacy, ma cambiare il linguaggio adesso sarebbe una cura peggiore del male. Guarda cosa è successo con Python3 (dopo 8-9 anni ancora la gente usa Python2) e con Perl5 (che ha praticamente ucciso il linguaggio). Il vantaggio di PHP è che ci sono decine di framework e librerie che ti permettono di non pensare più a quelle idosincrasie perché wrappano tutto in classi ed eccezioni con una API migliore. PHP non sta rimanendo affatto indietro, rispetto soprattutto a Python e Ruby. Anzi, sta crescendo a una velocità mostruosa: tipizzazione forte, nuova gestione delle eccezioni, performance che crescono ad ogni versione, ecc. Forse l'unico linguaggio dinamico che sta crescendo più velocemente è Javascript, ma richiede una conoscenza dei sistemi di compilazione che lo rende più difficile di PHP. Il fatto che rimanga indietro è relativo a due fattori, IMO. Il primo è il suddetto "haters gonna hate": gente che non prova nemmeno il linguaggio, ma non lo usa a prescindere e sconsiglia ad altri di usarlo. Questi tipicamente usano Js (con Node) per il web e Python per progetti più avanzati con magari una piccola interfaccia web. Il secondo è che alcuni linguaggi compilati (Go...) stanno "rubando" market share ai linguaggi dinamici grazie alle prestazioni e alla facilità di impararli (e all'hype). Il problema di entrambi è che la situazione è la stessa di PHP4: sono tutti emozionati dalla novità e non si accorgono che: 1- non tutte le librerie disponibili per PHP si trovano anche per quei linguaggi. Anzi, spesso non si trova proprio niente, o quello che si trova è molto limitato. 2- poca gente sa davvero usare bene le potenzialità di questi "nuovi" linguaggi (considero anche JS "nuovo" per via di ES6 e ES7) E infine, sempre valida la massima "ci sono 2 tipi di linguaggi di programmazione: quelli di cui tutti si lamentano, e quelli che non usa nessuno". Bye.
[toc] | [prev] | [next] | [standalone]
| From | fmassei@gmail.com |
|---|---|
| Date | 2018-08-03 17:23 -0700 |
| Subject | Re: [OT] Re: il ruolo di un validatore |
| Message-ID | <3a726eee-52e4-4207-a3b7-7e0a9298c9c3@googlegroups.com> |
| In reply to | #22132 |
On Friday, August 3, 2018 at 1:24:05 PM UTC-4, Alessandro Pellizzari wrote: > Il fatto che rimanga indietro è relativo a due fattori, IMO. > > Il primo è il suddetto "haters gonna hate": gente che non prova nemmeno > il linguaggio, ma non lo usa a prescindere e sconsiglia ad altri di > usarlo. Questi tipicamente usano Js (con Node) per il web e Python per > progetti più avanzati con magari una piccola interfaccia web. > > Il secondo è che alcuni linguaggi compilati (Go...) stanno "rubando" > market share ai linguaggi dinamici grazie alle prestazioni e alla > facilità di impararli (e all'hype). > > Il problema di entrambi è che la situazione è la stessa di PHP4: sono > tutti emozionati dalla novità e non si accorgono che: > IMHO, se prendi come riferimento un selfie su instagram di uno con l'ipad e didascalia "WTF PHP" vabbè, ma non è il riferimento che vogliamo. Almeno per me. A me, dispiace dirlo ma, a parte te, non vedo nessuno su ICWP competente abbasta per parlare del linguaggio. Facciamo una media, e disperiamoci :( > E infine, sempre valida la massima "ci sono 2 tipi di linguaggi di > programmazione: quelli di cui tutti si lamentano, e quelli che non usa > nessuno". > Questo purtroppo vale solo per chi programma da un po', e in più linguaggi... La massima che sapevo io, quando studiavo, era "c'è un linguaggio per ogni programmatore", visto che se ne doveva ideare uno per passare l'esame. Oggi boh: i nuovi laureati mi sembrano una massa di imbecilli. Ciao!
[toc] | [prev] | [next] | [standalone]
| From | g4b0 <g4b0@nospam.com> |
|---|---|
| Date | 2018-08-06 07:52 +0000 |
| Subject | Re: [OT] Re: il ruolo di un validatore |
| Message-ID | <pk8und$1r2d$2@gioia.aioe.org> |
| In reply to | #22132 |
Il Fri, 03 Aug 2018 18:24:02 +0100, Alessandro Pellizzari ha scritto: > On 03/08/2018 16:27, g4b0 wrote: > >> Il Fri, 27 Jul 2018 10:22:54 +0100, Alessandro Pellizzari ha scritto: > >> Quoto, soprattutto la parte che parla dei punti odiati. Provate a >> andare a parlate di PHP su i.l.i., vi massacrano a prescindere :D > > Haters gonna hate. :D :D Inoltre per "giustificare" i loro attacchi mi hanno postato link vecchi di 10 anni, con problemi perlopiù risolti. >> In parte hanno ragione, PHP dovrebbe darsi una rinfrescata, è vero che >> con PHP7 hanno migliorato molto, ma il linguaggio sta rimanendo >> indietro rispetto ai competitor. > > PHP ha un po' di rogne legacy, ma cambiare il linguaggio adesso sarebbe > una cura peggiore del male. > > Guarda cosa è successo con Python3 (dopo 8-9 anni ancora la gente usa > Python2) e con Perl5 (che ha praticamente ucciso il linguaggio). In effetti non avevo mai affrontato la questione da questo punto di vista. Confronto interessante. > Il vantaggio di PHP è che ci sono decine di framework e librerie che ti > permettono di non pensare più a quelle idosincrasie perché wrappano > tutto in classi ed eccezioni con una API migliore. Quoto. Da quando uso Laravel e Silex dormo sonni più tranquilli. > PHP non sta rimanendo affatto indietro, rispetto soprattutto a Python e > Ruby. Anzi, sta crescendo a una velocità mostruosa: tipizzazione forte, > nuova gestione delle eccezioni, performance che crescono ad ogni > versione, ecc. Questo è vero, sta crescendo, ma l'hype si sta spostando. Essendo un programmatore PHP non vorrei far la fine di chi sviluppava in Flash :) Guardandomi attorno le offerte che vedo in giro sono sempre più sbilanciate verso lo stack MEAN piuttosto che LAMP. Sarà una questione di hype, o ci sono dei reali vantaggi ad avere JS spalmato su tutto lo stack? > Forse l'unico linguaggio dinamico che sta crescendo più velocemente è > Javascript, ma richiede una conoscenza dei sistemi di compilazione che > lo rende più difficile di PHP. JS lo conosco, ci lavoro con Cordova per scrivere app, ed in quel contesto devo dire che non è male. IMO però ha dei gotcha molto più invasivi del PHP, checchè ne dicano gli haters innamorati di nodeJS. Ho provato anche a smanettarci lato server, sarà che sono abituato a PHP, ma non riesco proprio ad essere produttivo in quel contesto. Infilarmi in una callback hell, oppure scrivere n Promise, solo per leggere/scrivere da un file mi sembra un idiozia. Concordo sui vantaggi di un approccio asincrono, ma IMHO andrebbe usato in contesti dove attendere l'ouput diventa un problema e non a prescindere. > Il fatto che rimanga indietro è relativo a due fattori, IMO. > > Il primo è il suddetto "haters gonna hate": gente che non prova nemmeno > il linguaggio, ma non lo usa a prescindere e sconsiglia ad altri di > usarlo. Questi tipicamente usano Js (con Node) per il web e Python per > progetti più avanzati con magari una piccola interfaccia web. Anche i programmatori Java sono haters non male, pressochè tutti quelli di i.l.i. sono programmatori Java che odiano il PHP. > Il secondo è che alcuni linguaggi compilati (Go...) stanno "rubando" > market share ai linguaggi dinamici grazie alle prestazioni e alla > facilità di impararli (e all'hype). > > Il problema di entrambi è che la situazione è la stessa di PHP4: sono > tutti emozionati dalla novità e non si accorgono che: > > 1- non tutte le librerie disponibili per PHP si trovano anche per quei > linguaggi. Anzi, spesso non si trova proprio niente, o quello che si > trova è molto limitato. Quotissimo > 2- poca gente sa davvero usare bene le potenzialità di questi "nuovi" > linguaggi (considero anche JS "nuovo" per via di ES6 e ES7) E fai bene, con Typescript è diventato un altro linguaggio O_o > E infine, sempre valida la massima "ci sono 2 tipi di linguaggi di > programmazione: quelli di cui tutti si lamentano, e quelli che non usa > nessuno". Eheh, vero. g4b0
[toc] | [prev] | [next] | [standalone]
| From | Alessandro Pellizzari <shuriken@amiran.it> |
|---|---|
| Date | 2018-08-06 10:22 +0100 |
| Subject | Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) |
| Message-ID | <fsqiaiF8dgvU1@mid.individual.net> |
| In reply to | #22144 |
On 06/08/2018 08:52, g4b0 wrote: Cambiamo il subject, va. :) >> PHP non sta rimanendo affatto indietro, rispetto soprattutto a Python e >> Ruby. Anzi, sta crescendo a una velocità mostruosa: tipizzazione forte, >> nuova gestione delle eccezioni, performance che crescono ad ogni >> versione, ecc. > > Questo è vero, sta crescendo, ma l'hype si sta spostando. Essendo un > programmatore PHP non vorrei far la fine di chi sviluppava in Flash :) Vero. Personalmente mi sono spostato verso Go per lavoro (e Rust per hobby, finché non diventa abbastanza trendy per usarlo al lavoro), e nell'ultimo anno ho scritto un paio di centinaia di righe di PHP. Non perché ritengo PHP pessimo, ma perché il tipo di software che scrivo è diverso. > Guardandomi attorno le offerte che vedo in giro sono sempre più > sbilanciate verso lo stack MEAN piuttosto che LAMP. Sarà una questione di > hype, o ci sono dei reali vantaggi ad avere JS spalmato su tutto lo stack? Scomponiamo la sigla. :D MongoDB vs MySQL/PostgreSQL: hanno usi diversi. Vero che moltissimi problemi che la gente risolveva con un DB relazionale si adattano meglio a un DocumentDB, magari accompagnato da un KeyValue Store (tipicamente Redis). L'importante è sapere quando usare cosa. Express+Node vs PHP+framework: sono due modi diversi di affrontare il problema. Uno è stateful, l'altro stateless. Uno è asincrono, l'altro multiprocesso. I programmatori PHP che non capiscono la differenza sono mediamente MENO di quelli JS. :P Non hai idea di quanti sviluppatori JS ho visto scrivere ``` const data = fetch(...).then(v => v.data); // O quello che era console.log(data); ``` e lamentarsi del server o della connessione perché stampa undefined... Poi scoprono async/await e fanno tutto async/await. Poi gli mostri i generatori e non capiscono più niente. :P A presumo sia Angular. Tecnologia già morta. Tutti usano React e una buona percentuale sta andando verso Vue, abbandonando Angular. Praticamente Angular sopravvive in ambienti legacy. E stiamo parlando di un framework nato 4-5 anni fa... Personalmente preferisco un approccio `[A-Z]+` sia a MEAN che a LAMP: usa quello che va meglio per la situazione. Lo stack su cui sto lavorando adesso include Go, Elixir, Node+Express, Node+Express+React+Next, Nginx+Vue, con script (non web) in PHP e Python e sto appunto pensando di introdurre Rust per alcuni servizi che richiedono massima stabilità. Il problema è fossilizzarsi su un unico linguaggio, non su quale linguaggio. > JS lo conosco, ci lavoro con Cordova per scrivere app, ed in quel > contesto devo dire che non è male. IMO però ha dei gotcha molto più > invasivi del PHP, checchè ne dicano gli haters innamorati di nodeJS. Una sola domanda: what is this? :P > Ho provato anche a smanettarci lato server, sarà che sono abituato a PHP, > ma non riesco proprio ad essere produttivo in quel contesto. Infilarmi in > una callback hell, oppure scrivere n Promise, solo per leggere/scrivere > da un file mi sembra un idiozia. Concordo sui vantaggi di un approccio > asincrono, ma IMHO andrebbe usato in contesti dove attendere l'ouput > diventa un problema e non a prescindere. Per come la vedo io avere codice asincrono esplicito è un bug, non una feature, e infatti Go non ne ha bisogno: quando crei una goroutine è il runtime che si occupa di interrompere l'esecuzione quando fai IO e passarla ad un'altra goroutine. Non ha senso doverne tenere traccia con async e await. Quando voglio gestirlo esplicitamente mi creo un channel e ci aspetto sopra, esponendo sempre una API sincrona. Asincrono è importante. Multithread è importante, Multiprocesso è importante. Non significa che tutti li stiano facendo bene. Anzi. E nessuno dei tre è più importante di un altro. > Anche i programmatori Java sono haters non male, pressochè tutti quelli > di i.l.i. sono programmatori Java che odiano il PHP. I programmatori Java sono forse i primi haters della storia dei linguaggi di programmazione. :D Loro avevano Sun che gli diceva che erano i migliori (e adesso hanno Oracle), e i poveracci che sviluppavano in C e C++ non avevano idea di cosa si stessero perdendo. Per come la vedo io sono dinosauri entrambi. Il linguaggio è importante, ma l'ecosistema intorno, a partire dai package managers, è quello che fa la differenza. Prendi composer, npm, cargo e confrontali con maven e il nulla con il Makefile intorno che c'è per C/C++ (e parzialmente Go, per ora). Bye.
[toc] | [prev] | [next] | [standalone]
| From | fmassei@gmail.com |
|---|---|
| Date | 2018-08-06 08:10 -0700 |
| Subject | Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) |
| Message-ID | <133dc39a-045a-4a83-b6d7-98c5923bf4cc@googlegroups.com> |
| In reply to | #22145 |
On Monday, August 6, 2018 at 5:22:29 AM UTC-4, Alessandro Pellizzari wrote: > On 06/08/2018 08:52, g4b0 wrote: > > <snip> > > L'importante è sapere quando usare cosa. > <snip> > Personalmente preferisco un approccio `[A-Z]+` sia a MEAN che a LAMP: > usa quello che va meglio per la situazione. +10. Solo questo modo di pensare ha senso IMHO. > Per come la vedo io avere codice asincrono esplicito è un bug, non una > feature, e infatti Go non ne ha bisogno: quando crei una goroutine è il > runtime che si occupa di interrompere l'esecuzione quando fai IO e > passarla ad un'altra goroutine. Non ha senso doverne tenere traccia con > async e await. > Qui ci sarebbe da parlare un tot... E' lo stesso discorso che fanno i javisti quando dicono che gestire la memoria a mano è inutile visto che lo può fare la VM. Ci sono casi in cui non vuoi gestire threads, coroutines, sincronizzazioni, memoria, e chi più ne ha più ne metta, e casi dove invece è necessario. E lo dico da programmatore C che ama scrivere in Haskell :) Come dici te, è anche questione di gusti, ma alla fine è il progetto che detta i requisiti. > I programmatori Java sono forse i primi haters della storia dei > linguaggi di programmazione. :D > Loro avevano Sun che gli diceva che erano i migliori (e adesso hanno > Oracle), e i poveracci che sviluppavano in C e C++ non avevano idea di > cosa si stessero perdendo. > ... e come si offendono quando glielo si fa notare! ;) A me Java piacerebbe pure (in realtà no, ma c'è di molto peggio), ma i javisti non li posso proprio sopportare. > Per come la vedo io sono dinosauri entrambi. Il linguaggio è importante, > ma l'ecosistema intorno, a partire dai package managers, è quello che fa > la differenza. Prendi composer, npm, cargo e confrontali con maven e il > nulla con il Makefile intorno che c'è per C/C++ (e parzialmente Go, per > ora). > Questo invece non mi trova proprio d'accordo. Sia in Java che in C/C++ puoi trovare milioni in più di librerie e codici di ogni tipo, e una libreria con interfaccia C è utilizzabile con poco sforzo da praticamente qualsiasi linguaggio e ambiente moderno. Le uniche ragioni per cui non si programma tutti in C++ è che è difficile trovare sviluppatori decenti, i tempi di sviluppo sono di solito più lunghi, ed essendo un linguaggio compilato (la cui compilazione è un processo tutt'altro che leggero) non si adatta bene alle situazioni in cui servono solo degli scripts. Ciao!
[toc] | [prev] | [next] | [standalone]
| From | Alessandro Pellizzari <shuriken@amiran.it> |
|---|---|
| Date | 2018-08-06 16:31 +0100 |
| Subject | Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) |
| Message-ID | <fsr7uoFdatiU1@mid.individual.net> |
| In reply to | #22148 |
On 06/08/2018 16:10, fmassei@gmail.com wrote: > On Monday, August 6, 2018 at 5:22:29 AM UTC-4, Alessandro Pellizzari wrote: >> Per come la vedo io sono dinosauri entrambi. Il linguaggio è importante, >> ma l'ecosistema intorno, a partire dai package managers, è quello che fa >> la differenza. Prendi composer, npm, cargo e confrontali con maven e il >> nulla con il Makefile intorno che c'è per C/C++ (e parzialmente Go, per >> ora). > Questo invece non mi trova proprio d'accordo. > > Sia in Java che in C/C++ puoi trovare milioni in più di librerie e codici > di ogni tipo, e una libreria con interfaccia C è utilizzabile con poco > sforzo da praticamente qualsiasi linguaggio e ambiente moderno. Forse non mi sono spiegato bene. :) In JS fai `yarn add leftpad` e lui ti calcola le dipendenze, ti scarica quello che ti serve, ti configura packages.json con la versione corretta, e ti basta `yarn serve` e compila. In Rust metti `serde: "1"` in Cargo.toml sotto `[dependencies]`, dai `cargo install && cargo run`. No step 3. In PHP+Composer sappiamo come funziona. :) In Go devi comunque cercarti la libreria a mano, ma poi copi-incolli l'URL dentro il sorgente, una botta di `go get myapp` e te lo installa. In C/C++ non c'è niente di tutto questo. Devi scaricarti la libreria a mano, installarla, controllare se ha dipendenze, scaricarle, installarle, rinse-and-repeat, poi configurare gli autotools, lanciare ./configure che ti crea il Makefile, lanciare make. Le distro Linux rendono la vita un po' più facile, ma non sono integrate nel linguaggio, sono una pezza messa da altri. Maven non ho idea. Ho provato a usarlo una volta e non ho capito come funziona. Mi pare stiano cercando di fare qualcosa per C++, ma credo sia in alto mare. Bye.
[toc] | [prev] | [next] | [standalone]
| From | fmassei@gmail.com |
|---|---|
| Date | 2018-08-06 08:39 -0700 |
| Subject | Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) |
| Message-ID | <20f67593-60c3-4713-939a-1ad80b3a060a@googlegroups.com> |
| In reply to | #22149 |
On Monday, August 6, 2018 at 11:31:39 AM UTC-4, Alessandro Pellizzari wrote: > On 06/08/2018 16:10, fmassei@gmail.com wrote: > > > On Monday, August 6, 2018 at 5:22:29 AM UTC-4, Alessandro Pellizzari wrote: > > >> Per come la vedo io sono dinosauri entrambi. Il linguaggio è importante, > >> ma l'ecosistema intorno, a partire dai package managers, è quello che fa > >> la differenza. Prendi composer, npm, cargo e confrontali con maven e il > >> nulla con il Makefile intorno che c'è per C/C++ (e parzialmente Go, per > >> ora). > > > Questo invece non mi trova proprio d'accordo. > > > > Sia in Java che in C/C++ puoi trovare milioni in più di librerie e codici > > di ogni tipo, e una libreria con interfaccia C è utilizzabile con poco > > sforzo da praticamente qualsiasi linguaggio e ambiente moderno. > > Forse non mi sono spiegato bene. :) > > In JS fai `yarn add leftpad` e lui ti calcola le dipendenze, ti scarica > quello che ti serve, ti configura packages.json con la versione > corretta, e ti basta `yarn serve` e compila. > > In Rust metti `serde: "1"` in Cargo.toml sotto `[dependencies]`, dai > `cargo install && cargo run`. No step 3. > > In PHP+Composer sappiamo come funziona. :) > > In Go devi comunque cercarti la libreria a mano, ma poi copi-incolli > l'URL dentro il sorgente, una botta di `go get myapp` e te lo installa. > > In C/C++ non c'è niente di tutto questo. Devi scaricarti la libreria a > mano, installarla, controllare se ha dipendenze, scaricarle, > installarle, rinse-and-repeat, poi configurare gli autotools, lanciare > ./configure che ti crea il Makefile, lanciare make. > > Le distro Linux rendono la vita un po' più facile, ma non sono integrate > nel linguaggio, sono una pezza messa da altri. > > Maven non ho idea. Ho provato a usarlo una volta e non ho capito come > funziona. > > Mi pare stiano cercando di fare qualcosa per C++, ma credo sia in alto mare. > Se hai un progetto di un mese per un team di quattro persone, far perdere cinque minuti o un'ora ad una di queste il primo giorno, non cambia praticamente nulla sullo schedule, anche visto che comunque leggere la documentazione di tale liberia toglie molto più tempo. ;) Certo, sarebbe meglio non doverlo fare, ma come sai rimuovere la possibilità di poter configurare manualmente certi pezzi non è considerato accettabile nella maggior parte degli ambienti dove si usa C++. Ciao!
[toc] | [prev] | [next] | [standalone]
| From | Alessandro Pellizzari <shuriken@amiran.it> |
|---|---|
| Date | 2018-08-06 18:03 +0100 |
| Subject | Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) |
| Message-ID | <fsrdarFeiliU1@mid.individual.net> |
| In reply to | #22150 |
On 06/08/2018 16:39, fmassei@gmail.com wrote: > Se hai un progetto di un mese per un team di quattro persone, far perdere > cinque minuti o un'ora ad una di queste il primo giorno, non cambia > praticamente nulla sullo schedule, anche visto che comunque leggere la > documentazione di tale liberia toglie molto più tempo. ;) Vero, ma, di contro, posso dirti che ho prototipato microservices in Go nel giro di 2 ore, e in un caso quel prototipo poi è diventato production-ready solo aggiungendo il logging remoto e un po' di gestione degli errori (altre 2-3 ore). In mezza giornata ho scritto un app CLI in Rust che mi analizza una directory e calcola gli hash dei file per trovare duplicati. In parallelo su n thread basata sul numero di core della macchina... :) In C/C++ non avrei nemmeno finito di scaricare e installare le librerie giuste. > Certo, sarebbe meglio non doverlo fare, ma come sai rimuovere la possibilità > di poter configurare manualmente certi pezzi non è considerato accettabile > nella maggior parte degli ambienti dove si usa C++. Per quello dico che sono dinosauri. :D Sono rimasti a uno stile di sviluppo di 20 anni fa, e secondo me la pagheranno nel corto-medio periodo. Mi rendo conto che il sistema a microservizi è tipicamente web, e non si applica, per esempio, a microcontrollori o a buona parte delle app desktop, ma ugualmente si potrebbe applicare alla separazione dell'app in librerie: definisci un'API per ogni pezzo dell'app e ogni persona si concentra su quello. Ogni pezzo è testabile per conto suo, la struttura dell'app è più pulita, ogni sviluppatore deve tenere in testa meno informazioni. Ma senza un sistema di gestione delle dipendenze fai presto a diventare matto, e tendi a continuare a ragionare in monolitico. Bye.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | it.comp.www.php
csiph-web