Quote Originariamente inviata da giannino1995 Visualizza il messaggio
Usando python perdo delle funzionalità nella programmazione
Uhm, no, ottieni roba diversa. Non hai la tipizzazione statica, le performance di un linguaggio compilato e diverse altre cose, ma guadagni un sacco di possibilità a livello di espressività del linguaggio, librerie pronte all'uso, semplicità di utilizzo, facilità di deployment, portabilità del linguaggio, minori problemi di sicurezza... non a caso, se non ci sono problemi di performance (ed è questo in genere il caso di molte applicazioni web) si preferisce lavorare con linguaggi di livello più alto.
e soprattutto fatico ad usare il codice python insieme al codice C++.
Perché dovresti usarli insieme, se non per problemi di performance? Di base lavora in Python, se ti serve velocità scriverai in C++ usando software come SIP per generare il binding.
Perché non creare un framework di C++ o semplicemente delle nuove classi o altro ancora capace di dare più forza al linguaggio?
Al di là del fatto che gli script CGI si scrivono in C o C++ dalla notte dei tempi, comunque un framework relativamente noto per fare siti in C++ esiste - cerca CppCMS. Ma in generale, sono molto pochi quelli che lo utilizzano, perché in ambito web in genere si preferisce lavorare con qualcosa di più comodo e meno rischioso (a livello di undefined behavior, buffer overflow & co.) del C++ (oltre al fatto che il deployment è una menata, devi sapere esattamente per che piattaforma compili).
PHP di fatto cos'é? E' un "qualcosa" che deriva dal C/C++!
Stai partendo per una tangente non molto sensata - sì, l'interprete PHP è scritto in C, ma questo non significa che tu puoi scrivere dentro ad un programma C come se fosse PHP; in altre parole, usi il C per costruire un interprete che ti consente di usare una sintassi e una semantica che tu dentro ad un programma C non potresti mai avere. Sì, il C++ con tutti i giochini di template, overload degli operatori e compagnia è molto più flessibile, ma comunque ci sono delle limitazioni grosse (niente garbage collection, scarsissima reflection, in generale poca dinamicità a runtime, macro poco potenti, ...) a cui i rimedi "dentro al linguaggio" tendono ad essere peggiori del male.
In generale, la stragrande maggior parte dei compilatori e degli interpreti è scritta in C o C++, ma questo non vuol dire assolutamente che direttamente in C o C++ tu possa lavorare come fai, che so, in Lisp, Ruby o Erlang.
In generale, ci sono paradigmi di programmazione che C++ non può nemmeno provare a simulare proprio per come è impostato (prova ad implementare delle continuation o coroutine in C++ standard).
Java cosè? Un programma che permette di scrivere codice fatto in C/C++!
Uhm, la questione è discretamente più complicata... è vero che gran parte della JVM è scritta in C o C++, ma c'è di mezzo anche un JIT-compilatore, che dal bytecode Java genera direttamente codice macchina ottimizzato...
Sempre di C++ si parla, di diversi approcci, questo si. Puoi dirmi che non tutti siano fermamente convinti sull'approccio progettuale e che quindi per evitare di litigare si siano scelti più standard, PHP, JAVA, ecc... però resto dell'ipotesi che si dovrebbe cominciare con più forza a pensare ad un solo linguaggio e non a 1200 versioni della stessa frittata.
Non è questione di evitare di litigare, è questione che diversi linguaggi sono indicati per fare cose diverse, hanno punti di forza e debolezza diversi e riflettono impostazioni mentali diverse. Non è vero che tutti sono una qualche ribollitura del C++ - quando scrivo in C, in C++, in Python, in bash, in JavaScript, ... spesso imposto le cose in maniera radicalmente diversa, perché il linguaggio tende a spingere in una direzione o nell'altra; ora che sto studiando Erlang, vedo che un buon 50% del modo di pensare dei linguaggi imperativi viene completamente buttato via in un linguaggio funzionale.
Io non sono un programmatore e studio da autodidatta con entisiasmo ma non condivido questo pensiero di settorializzare invece di standardizzare.
Seguendo questo ragionamento oggi staremmo tutti scrivendo in Cobol.