Be “pythonic”

Da qualche tempo ho iniziato a sviluppare seriamente in Python. In questi anni ho utilizzato buona parte dei linguaggi di programmazione più diffusi: C/C++ per applicazioni embedded, Pascal (Delphi) e Visual Basic all’inizio, PHP e Javascript per il web, Perl per gli script, Java per qualche applicazione sfortunata (odio Java), C/SIDE per Dynamics, T-SQL per i database e poi tanto tanto C#. Che bisogno c’era di un nuovo linguaggio?

Vi traduco un articolo di Anthony Shaw che riassume il mio pensiero.

Perché ho scelto Python al posto di C# come mio linguaggio preferito (e non intendo tornare indietro)

Non sono uno “sviluppatore professionista”, non lo mai stato. Sono un pensatore, un hacker, un innovatore e (ad un certo punto) un product manager. Non sviluppo per denaro, sviluppo per divertimento e faccio innovazione per denaro (il che implica un sacco di programmazione).

Ho portato indietro il mio Surface Book al Microsoft Store dopo 6 mesi tormentati da problemi e frustrazioni ed ho realizzato che non userò mai più Visual Studio: non svilupperò più in C# e Python è ora la mia scelta. Non è una decisione totalmente consapevole, sono pigro ed uso qualsiasi cosa che mi aiuti a fare il mio lavoro più velocemente ed in qualche modo andrò da 100% C# a 100% Python.

Lasciatemi spiegare alcune ragioni di questa scelta. Sono certo che molti sviluppatori non hanno il lusso di poter scegliere, ma questo articolo è un tentativo di incoraggiare gli sviluppatori C# a dare una chance a Python senza farsi un’opinione superficiale.

L’ecosistema Web in C# è ad un solo binario

Microsoft .NET è sia la libreria di base che il CLR. C# in sé è un linguaggio che ha il suo compilatore che crea gli eseguibili CLR. Nel 2016 creavo le mie applicazioni con semplici pacchetti riutilizzabili, come servizi oppure come API che potevano essere utilizzati dalla UI. Quando ho fatto la UI per un servizio, ho separato il controllo del backend dal frontend in due progetti distinti, così da fornire delle API REST agli utenti.

Nell’ecosistema .NET, Microsoft produce gli strumenti e tu devi raccoglierne i frutti.

Nel 2011 c’era WCF Data Services for REST-ful appplications, poi nel 2013 abbiamo avuto OWIN in Katana, che ha rimpiazzato l’intero stack con una versione più leggera. Poi nel 2014/2015 abbiamo avuto ASP.NET WebAPI, poi ASP.NET WebAPI 2 (con alcuni cambiamenti notevoli).

Infine abbiamo avuto ASP.NET 5 WebAPI (che ha cambiato il suo nome in ASP.NET Core) e adesso ASP.NET MVC 6. Ogni volta cambiano le interfacce, cambiano i namespace, cambiano i contratti e le best praticies vanno completamente buttate via. Ogni modulo riutilizzabile che hai fatto per loggare, per statistiche o autenticazione va buttato e riscritto.

Questo è frustrante.

Quindi dovrebbero smettere di evolvere? Certamente no, ma creare un servizio che riceve dei messaggi HTTP/RESTful ed esegue del codice è una cosa abbastanza elementare. Inseguire l’ecosistema Microsoft che continua a cambiare, costa tempo e denaro, senza dare benefici alle mie applicazioni.

Con Python posso invece scegliere quale framework REST utilizzare e rimanere con quello. Alcuni sono veramente semplici e leggeri, come Flask, Bottle o Pecan, altri sono ricchi di funzionalità, come Django-REST.

Ne scelgo uno, lo imparo e lo tengo (ho scelto Flask-RESTful).

Non riesco mai a trovare le librerie che cerco in NuGet.org

Volevo scrivere una piccola applicazione che avviasse un container docker per gestire alcuni servizi cloud. Ho pensato di utilizzare Rancher, Kubernetes e CoreOS Fleet. In C# con NuGet.org Kubernetes ha 1 pacchetto KubeNET che è una libreria autogenerata senza documentazione. Per Rancher e Fleet non c’è nulla.

Su pypi.python.org ho invece una vasta scelta, documentazione e licenze incluse. Kubernetes? kubernetes-py, pykube, kploy, python-kubernetes. Ho guardato e scoperto che una libreria ha la migliore documentazione API e rispetta i miei requisiti di licenza. Rancher? Rancher-metadata, cattle-prod, cattle. Fleet? FleetPy, PyFleet and Fleet.

OK, se rimango con .NET devo scrivere la mia applicazione e pubblicare anche una libreria client per qualsiasi tool che intendo utilizzare. La stessa cosa per i progetti IoT o hardware che ho fatto.

NuGet.org è pieno di librerie abbandonate e senza licenza

Al momento in cui scrivo questo articolo, i primi 10 pacchetti su NuGet.org sono:

Newtonsoft.JSON, jQuery e EF6 sono Open-Source (MIT, EF6 is Apache2), System.IO, System.Reflection e System.Runtime sono in licenza Microsoft. Ci sono un sacco di pacchetti chiusi o senza licenza su nuget.org. Quando incontro un problema, vorrei risolverlo e inviare un pull-request per migliorare l’ecosistema. Lo status quo regna in nuget dove lo stile di pubblicazione sembra essere “spara e dimentica”.

Su PyPI, l’immagine è leggermente diversa, quasi tutto è open-source. I progetti più popolari tendono ad avere molti collaboratori e sono molto ben mantenuti. Certo c’è sempre qualcosa di abbandonato, ma è meno frequente (e lo puoi segnalare tramite il sito web). Vedere ripubblicare i pacchetti dopo che le tue fix sono state accettate è anche un po’ stimolante.

Le persone sembrano non preoccuparsi di documentare i pacchetti .NET

In Python c’è Sphinx il modello di default che produce la cartella di documentazione e test per il codice sorgente. Puoi pubblicare su ReadTheDocs con il minor sforzo possibile. Come conseguenza, un sacco di pacchetti che ho scaricato da PyPI sono documentati.

Per .NET ho dovuto utilizzare powershell, stylesheet XML, AppVeyor e generare della documentazione è stato un incubo. Apparentemente sono l’unico che ha provato a generare automaticamente della documentazione per NuGet.

.NET funziona solo su Windows

Non ho bisogno di spiegarlo, ma Linux è una cosa concreta, la gente lo usa! E’ inevitable che affrontando qualcosa che è fatto solo per Linux si debba evitare .NET. Certo, DotNetCore sta colmando questo gap, ma ci vorrà molto tempo per abituare le persone a pensare con un diverso sistema operativo (e filesystem). Far partire semplicemente gli eseguibili è solo una piccola parte del problema.

L’articolo originale: https://medium.com/@anthonypjshaw/why-i-swapped-c-net-for-python-as-my-default-language-and-platform-and-wont-be-going-back-e0063a25e491

 

Chiama subito per maggiori informazioni +39 0113473770
oppure lasciaci i tuoi recapiti e sarai contattato il prima possibile:



 

Lascia un commento