[Python] Python vs Java

[enrico franchi]

2014-12-30 0:01 GMT+01:00 Carlos Catucci <carlos.catucci a gmail.com>:

>
> 5. HTML/Templating, verosimilmente con CSS e quel minimo di Javascript che
> tende a saltare fuori ovunque
>
> No, perdonami, ma io separo frontend e backend. La parte "browser" la fa
> una figura diversa e per essere formata richiede altri tempi (javascript
> senza contare poi css e compagnia, e' motlo piu' complesso.). Io parlavo di
> Python e Django.
>

Continuo a vedere un problema di fondo... oh, de gustibus. Ma questa e' una
figura proprio *non* autonoma. Cioe' tu dici si, che non e' autonoma. Ma
questa e' una figura che gli dici fai una funzione che divide per due ogni
elemento di un array e fine della fiera. Cioe' se non sai con chi parli
sopra e sotto... boh, non mi e' nemmeno chiaro se sia utile o se il tempo
che si perde a dire cosa deve fare per filo e per segno sia piu' di quello
che ci va per farsele da soli. Ma qui divaghiamo.

Dopo di che, sei tu ad avere tirato in ballo django. A me sembra che
parlare di Django ed escludere meta' delle cose che fa django sia un po'
controintuitivo.


> 5b. Forms e compagnia
>
> Anche qui non e' strettamente necessario. Io le forms non le ho mai usate
> in progetti fino ad ora. Sono belle, sono comode, ma non indispensabili.
>

Hei, ci sono le django form e le form HTML. Cioe' il fatto che il poverino
non possa scrivere un coso che prende un qualche tipo di input dall'utente
per fare una modifica sul db e' parecchio limitante....


> 6. Come si gestiscono e come non si gestiscono gli errori, quando usare
> None, quando tirare un'eccezione, quando fare altro. Come gestire le
> eccezioni, quando rilanciarle, quando gestirle, quando fare cosa
>
> Le eccezioni si, fanno parte del linguaggio
>

Non e' solo le eccezioni come concetto astratto. Ma *come* e *quando*
usarle (e quando non usarle), come e quando gestirle e quando non farlo. Io
vedo che la gente prima di progettare la gestione dell'errore in modo
robusto ci mette *parecchio* tempo e a volte cazza anche la gente esperta
(cazza di rado, certo). Il che mi fa pensare che la gente *poco* esperta...
cazzi molto di piu'.

Ma tu parli di codice robusto e mantenibile. Il che vuole dire che stai
sostenendo che in 10 giorni, insieme a tutto il resto, spieghi una cosa
difficile di suo, che richiede sapere esattamente cosa e quando possa
andare male, per fattori spesso esterni dipendenti dal sistema operativo,
da altri sistemi, dalla rete, dal carico, da chenneso'... io qui dubito
molto.

Oh, ma tu sostieni anche di spiegare la OOP, in due giorni o giu' di li
(visto tutto il resto che devi spiegare nei 10 giorni).


> 7. Testing (che non vorremo mica sviluppare senza test, spero)
>
> Si i test li prepara e esegue una persona diversa, Con il tempo e
> l'esperienza imparera'. Ma per scrivere dei buoni test devi prima conoscere
> bene il linguaggio ed il framework
>

Ah, ok. Allora *non* stiamo parlando di codice robusto e mantenibile. Era
quello che sostenevo da subito.

>
> 9. Quel poco di SQL (o meglio, di db relazionali) che ti serve per capire
> come accidenti Django salva e legge dati, fra le altre varie cose per non
> inchiodare tutto appena la gente comincia ad usare il servizio
>
> Per questa fase gli basta di sare eseguire le query con gli statement
> dell'ORM. Le raw query servono solo in casi particolari che esulano, per la
> fase iniziale.
>

Nessuno ha parlato di raw query. Ma non mi e' chiaro come puoi scrivere
codice robusto usando un'astrazione senza sapere quello che astrai e quello
che generi. Mi sembra il classico caso in cui uno si trova con qualcosa che
funziona male ma non ha idea del perche'. Ma anche cose facili tipo quando
e dove mettere gli indici, i vincoli vari, le fkeys... tutto dall'orm, eh.
Ma roba che va fatta... ma che per essere fatta ha bisogno di sapere i
concetti sottostanti (da cui parlavo di sapere come funzionano i db
relazionali).


> 11. Come funzionano le fixtures e come si scrivono i test che
> interagiscono con il db
>
> No perche' qui pure siamo nel "e' compito di altra persona", in questa
> fase-
>

Boh... non mi e' chiaro come pensi che uno scriva codice robusto senza fare
i test, vomitando fuori codice che poi qualcun altro dovra' testare. Il che
genera un monte di ritardi, espone a problemi di comunicazione fra le due
persone, riduce la validita' e l'utilita' dei test stessi.

12. cosa loggare e cosa non loggare, quando, come leggere e capire un log
>
> Beh fa parte della programmazione, senza log non fai debug
>

In realta' dissentireri... i log hanno soprattutto un'altra funzione, ma
tant'e'.
Cioe' il debug fatto a print mi fa cosi' tanto ... vabbe'.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20141231/3d6550f0/attachment.html>