La programmazione a oggetti serve nel campo dello sviluppo web?

[MItaly]

Ma il punto è che quelli elencati da me non sono affatto problemi. E quell' articolo è pieno di situazioni del genere.
Quindi prendere come spunto l'articolo in oggetto, per dire php ha un sacco di problemi, è a mio avviso fuorviante.

Se leggi quell'articolo e non ti metti le mani nei capelli vuol dire che PHP è veramente pericoloso, perché fa pensare che incoerenze e comportamenti assurdi o tollerabili in praticamente ogni altro linguaggio a piccole dosi siano una cosa normale; sorry, è PHP l'anomalia. O quello, o sindrome di Stoccolma.
Inoltre, numerose anomalie lì riportate (parser ridicolo, identificatori "magici" mal inquadrati nel resto del linguaggio, pezzi di semantica del linguaggio mal copiata da altrove, rilasci ufficiali con più di metà degli unit test falliti , ...) sono testimonianza di come lo sviluppo sia partito e sia poi stato portato avanti in maniera estremamente poco rigorosa e quasi amatoriale da gente che di linguaggi "normali" ne sa molto poco.

Che si riesca a lavorare con un pasticcio del genere comunque non è l'argomento della discussione (e tra l'altro ti viene data una risposta all'inizio dell'articolo: sì, si può piantare un chiodo con un martello senza testa, ma resta un'idea idiota).

Se la domanda è "è un buon sistema per imparare la OOP" sono d'accordo con scara95 che la risposta è senz'altro "no", visto che per imparare per bene i concetti della OOP è utile lavorare con una sua implementazione ben fatta e che rispecchi il più possibile nel linguaggio quelli che sono i principi generali, e vederla applicata nella libreria standard, in modo da vedere anche come si usa. In PHP la OOP è una cosa attaccata su con lo scotch, copiando un po' da Java (ma in un linguaggio che di Java non ha nulla, per cui il risultato, tanto per cambiare, è un'arlecchinata), e il 90% della libreria standard è procedurale (oltre ad essere un pasticcio incoerente).

C# è mille volte meglio di PHP per iniziare con idee giuste. Implementa una OOP "alla Java" (quindi senza ereditarietà multipla - rimpiazzata con il più ristretto concetto delle "interfacce" - e con un po' di "ingessature"), ma la implementa in maniera ordinata, chiara e armonizzata con il resto del linguaggio, e ti trovi immerso subito in una libreria standard (il .NET Framework) che è pensata fin dall'inizio orientata agli oggetti.

[ciro78]

Se leggi quell'articolo e non ti metti le mani nei capelli vuol dire che PHP è veramente pericoloso, perché fa pensare che incoerenze e comportamenti assurdi o tollerabili in praticamente ogni altro linguaggio a piccole dosi siano una cosa normale; sorry, è PHP l'anomalia. O quello, o sindrome di Stoccolma.....

cut

Come ho detto non ho letto tutto l'articolo. Ho evidenziato solo come si riempia una pagina con delle assurdità facendole passare per problemi dando a mio avviso, la percezione che php è il male.

Detto questo il punto non è quale linguaggio è migliore. E' ovvio che c# sta a php come una divinità sta al comun mortale.

Ma se un utente deve imparare che cos'è un oggetto, una classe e un interfaccia a mio avviso php va bene.

Che il 90% delle librerie php siano in procedurale ad un programmatore che comincia non può che tornare comodo. Il mio vecchio manuale di PHP, molto vecchio, mise i concetti della oop solo alla fine.

Il manuale su cui studiai il c# cominciò dicendo che tutto derivava da object. Questo si traduce che chi non sa cosa vuol dire oggetto né cosa si intende per deriva...si perde dopo due righe.

[Scara95]

Come ho detto non ho letto tutto l'articolo. Ho evidenziato solo come si riempia una pagina con delle assurdità facendole passare per problemi dando a mio avviso, la percezione che php è il male.

Detto questo il punto non è quale linguaggio è migliore. E' ovvio che c# sta a php come una divinità sta al comun mortale.

Ma se un utente deve imparare che cos'è un oggetto, una classe e un interfaccia a mio avviso php va bene.

Che il 90% delle librerie php siano in procedurale ad un programmatore che comincia non può che tornare comodo. Il mio vecchio manuale di PHP, molto vecchio, mise i concetti della oop solo alla fine.

Il manuale su cui studiai il c# cominciò dicendo che tutto derivava da object. Questo si traduce che chi non sa cosa vuol dire oggetto né cosa si intende per deriva...si perde dopo due righe.

PHP è il male se devi imparare in modo serio a programmare, qualsiasi cosa tu debba imparare, PHP puoi casomai utilizzarlo quando hai già conoscenze salde e quindi sai come puoi aggirare tutti i vari problemi che lui ti crea!

Se C# sta a PHP come una divinità sta ad un comune mortale non vedo perché non utilizzare C#. Anche se comunque la cosa non è affatto ovvia e ad esempio per alcuni progetti web potrebbero risultare assai più utili linguaggi diversi dal C#.

Con PHP se riesci a capire a che ti serve un oggetto sei fortunato. Se si può fare tutto implementando le cose a forza di primitive e quella parte di libreria standard che c'è è totalmente procedurale, perché devo io (un io generico) mettermi ad utilizzare gli oggetti che mi creano solo problemi ad usarli col resto, anche con gli operatori di confronto che operano esattamente all'opposto con gli oggetti e con i tipi primitivi.

Il metodo di insegnamento è discutibile, partire già con l'idea di oggetto e delinearla per bene o partire da una concezione procedurale per poi aggiungere gli oggetti è una questione di gusto. Certo se parti da una concezione procedurale vedi gli oggetti come un surplus e un qualcosa che non fa altro che appesantire (cosa che secondo me è vera in molti casi, quando effettivamente l'ereditarietà è portata troppo all'estremo e non fa altro che indurre complicazioni, ripeto: in certi casi e quando l'ereditarietà è portata all'estremo, l'ereditarietà che è scollegata dall'incapsulamento, tanto che gli oggetti esistono anche senza ereditarietà, non voglio creare guerre ideologiche). E in ogni caso ci sono tanti altri linguaggi che ti permettono di sviluppare (apparentemente) senza oggetti, ad esempio il sopra citato Python, oppure Ruby, ...

In C# sei costretto a introdurre subito gli oggetti, altrimenti non scrivi neanche il main. Questo comunque, come già ho detto, ha sia vantaggi che svantaggi, dipende dal metodo d'insegnamento e c'è chi (insegnante) preferisce uno e chi preferisce l'altro. Io personalmente preferisco l'introduzione immediata degli oggetti, ma è solo una mia opinione.
In ogni caso per il "non capisce niente" pensa a tutte le tecniche di insegnamento (anche delle lingue parlate ad esempio) ad immersione, ai corsi in lingua, ai laboratori e all'apprendimento per sperimentazione, in cui l'apprendimento è graduale perché i concetti vengono spiegati gradualmente e si capiscono appunto per sperimentazione.
Ad ogni modo tu hai capito comunque, dato che stai usando C# e non è detto che tutti i manuali comincino come il tuo.
Per fare un analogo con la programmazione procedurale: tanti corsi C cominciano col dire "devi sempre scrivere

#include <stdio.h>

int main(int argc, char **argv) {

  return 0;
}

e in mezzo metterci il codice perché la funzione main è fondamentale e devi sempre includere le librerie" per spiegare il tutto solo poi, il punto è lo stesso: come non sai cos'è un oggetto, non sai cos'è una funzione. E non dire che già la conosci prima di cominciare a programmare perché l'idea che si ha di funzione è profondamente diversa da quella che ne ha un linguaggio di programmazione non puramente funzionale.

[ciro78]

Se C# sta a PHP come una divinità sta ad un comune mortale non vedo perché non utilizzare C#. Anche se comunque la cosa non è affatto ovvia e ad esempio per alcuni progetti web potrebbero risultare assai più utili linguaggi diversi dal C#.

Perché non sempre dipende da te la scelta. Spesso il cliente dispone di hosting LAMP e non intende cambiare.