Cresce la popolarità di Swift all’interno delle community di programmatori

10 Marzo 2017 88

Presentato ufficialmente nel corso della WWDC 2014, Swift è un linguaggio di programmazione estremamente recente che, stando alle recenti statistiche, sta acquisendo una popolarità sempre maggiore all'interno della community di riferimento.

A proporci alcuni dati ci pensa TIOBE Index, un indice che calcola i dati raccolti dai motori di ricerca, in modo da stimare la popolarità di un determinato linguaggio di programmazione tra le comunità online dedicate all'argomento. In base a quanto riportato dalle analisi di questo mese, Swift si piazza al decimo posto della classifica, guadagnando 4 posizioni rispetto ad un anno fa.

Ovviamente i piani alti della graduatoria sono occupati dai mostri sacri, come Java, C, C++ e C#, presenti sulla scena da diverse decadi. Il loro radicamento è senza dubbio indiscutibile, tuttavia è interessante notare come Objective C, il linguaggio che Swift si pone l'obiettivo di sostituire, stia gradualmente perdendo popolarità, arrivando solo al sedicesimo posto.


Come abbiamo visto negli scorsi mesi, Swift è stato particolarmente apprezzato in ambito educativo, grazie al rilascio di Swift Playgrounds, l'applicazione sviluppata da Apple per avvicinare i più giovani al mondo della programmazione, tramite giochi e quiz che li introducano alle meccaniche che stanno alla base di un linguaggio di programmazione.

Playgrounds ha debuttato assieme all'attuale versione 3.0 di Swift, la quale potrebbe essere presto aggiornata alla 3.1 in occasione della prossima WWDC che si terrà a giugno. Ma non solo giovani, dal momento che la conoscenza di Swift sembra essere una delle abilità più ricercate all'interno del curriculum degli sviluppatori freelance.

Schermo enorme ma dimensioni decisamente contenute. Display bellissimo e batteria ampia? Samsung Galaxy S8 Plus, compralo al miglior prezzo da Amazon a 628 euro.

88

Commenti

Regolamento Commentando dichiaro di aver letto il regolamento e di essere a conoscenza delle informazioni e norme che regolano le discussioni sul sito. Clicca per info.
Caricamento in corso. Per commentare attendere...
Gabriele Di Bari

Si, ma infatti l'incapsulamento ha un suo perché, puoi sempre truccare modificando il tipo, esempio 'int m_age', in 'only_read<int> m_age',
Insomma ci sono metodi per ovviare al problema, solitamente in C++ tra trick e hacks si riesce sempre ad uscirne.
E questo é un bene, come un male (sicurezza portami via).

Diciamo che si hanno degli svantaggi come vantaggi.
Ad esempio fare dei wrapper é estremamente semplice, ad esempio con MPI, per descrivere una struttura da inviare con dei messaggi su un claster ho scritto questa funzione:

template < typename C, typename R>
mpi_data_field mpi_attr(R C::*M, const size_t size = 1)
{
using attr_type = decltype( ((C*)0)->*M );
using attr_array= typename std::remove_reference< attr_type >::type;
using attr = typename std::remove_extent< attr_array >::type;

return
{
type< attr >(),
reinterpret_cast<std::size_t>(&(((C*)0)->*M)),
size
};
}

template < typename C, typename R>
mpi_data_field mpi_attr(mpi_handle type, R C::*M, const size_t size = 1)
{
return
{
type,
reinterpret_cast<std::size_t>(&(((C*)0)->*M)),
size
};
}

Cosí 'creare una struttura MPI partendo da una raw, con 3 righe

mpi::type_create_struct(
{
mpi::mpi_attr(&shared_attributes::m_np),
mpi::mpi_attr(&shared_attributes::m_sigma),
mpi::mpi_attr(&shared_attributes::m_emedia)
});

ale

Però non va bene neanche lasciare public, perché se mettiamo che più avanti ti viene in mente di aggiungere per esempio un controllo tale per cui in una proprietà puoi settare solo certi valori, eh ti tocca cambiare anche tutto l'altro codice, invece di modificare solo i metodi set/get della tua classe o modificare la proprietà in C#. Altro problema, mettendolo public non puoi per esempio consentire solo il get e non il set, ossia avere una proprietà read only e magari avere solo il set private.

Ovvio che poi tutto dipende da cosa vuoi fare, se hai una struct con 3 valori si allora li lasci public, membri di una classe grossa, non è buona programmazione

Gabriele Di Bari

Diciamo che l'escamotage con i template e overload degli operatori ti permette di emulare GET e SET di C#, certo non è la stessa cosa.
Comunque solitamente l'approccio è proprio quello descritto tra parentesi da te, ovvero: se set e get sono dei meri return x, x = value allora lo lascio pubblico.

ale

Più che altro, si fa sentire anche la mancanza delle proprietà, scrivere metodi get/set è fastidioso ed allunga un casino il codice (sempre che uno non decida di mandare a quel paese l'incapsulamento e lasci tutto public)

Gabriele Di Bari

Si, in generale puó portare a porcate (il C++ come grande difetto ha questo, ma é la sua filosofia), ma se ben Usato permette di risparmiare codice, e diciamo che quando manca si fa sentire (come viceversa si fa sentire la mancanza di un sistema di reflection decente, ed anche il build system moderno come su c# che con le namespace é fantastico, mentre su c++ si va ancora ad header + binario stile C).

DarioDP

Solo una parola: LINQ

ale

Forse mi sono espresso male, più che tanti costrutti, forse ne ha meno, C++ ha tanto costrutti complicati, in C# quando vedi una cosa, dici si ovvio logico che va fatta in questo modo.

Mentre i costrutti di C++ sono tutto fuorché semplici, già solo allocare un oggetto, devi specificare se allocarlo sullo stack, o sull'heap, se usare un puntatore, o uno smart pointer, e se mai quale dei 3 tipi che ci sono, devi distinguere il caso che un oggetto sia allocato sull'heap piuttosto che sullo stack ed accedervi quindi con -> (cosa odiosa). O decidere se passare per riferimento piuttosto che reference o piuttosto che passare il puntatore.

Il rust come costrutti non ne ha neanche tantissimi, solo che quelli che ha sono complicati perché essenzialmente prendono come base la programmazione funzionale (i trait sono presi identici da haskell) e quindi è difficile (perché bisogna imparare a programmare in altro modo)

ale

Ah si quello non si può fare, boh può piacere o meno, secondo me una scrittura del genere è meno chiara e capibile "al volo" rispetto che chiamare i relativi costruttori. Più corto da scrivere sicuramente, poi sono dettagli

Gabriele Di Bari

Guarda che anche C# ha una mare di costrutti, piú costrutti non vuol dire maggiore difficoltà (altrimenti rust che sarebbe? Il diavolo?)
Il C++ moderno non ha praticamente niente che gli manca rispetto al Java (che possiamo definire un Micro sottoinsieme), diverso é c# con il quale sparisce molte caratteristiche, ma spesso le stesse fixtures le attua in modo differente, ma entrambi i linguaggi hanno caratteristiche che l'altro non ha.

Gabriele Di Bari

Non esattamente, per type deduction intendo la deduzione del tipo, ad esempio:
struct v2 { float m_x, m_y ;};
std::vector< v2 > so points { { 1,2}, { 4,5}};
Il compilatore capisce che deve chiamare il costruttore di vector che usa initialization list di v2 che a sua volta deduce (dal fatto che non ha un costruttore se non quello di default) che va inizializzato seguendo usando il memory layout della classe/struct (in c++ sono la stessa cosa).
Questo concetto si applica a tutto, dove il tipo é deducibile c++ lo deduce :).

Sì, intendo il tipo di pattern matching usato in rust, visto ora in C# 7, interessante, felice di vedere tale caratteristi presentata in C# (che ripeto trovo un ottimo linguaggio e che in definitiva consiglio ai piú nei casi piú disparati).

ale

Con type deduction penso ti riferisca al type inference, quello che in C++ si fa con auto, e ovviamente c'è in C# (si fa con var). Con argument matching non so a cosa ti riferisca di preciso, penso sia il pattern matching (quello che in rust fai con match ?), e se è quello, si in C# 7.0 appena uscito lo hanno introdotto, cosa molto comoda.

ale

Più moderno di C# o Java, no ce ne vuole ancora, soprattutto per C# ha veramente un mucchio di features che C++ non ha.

Più costrutti non sempre vuol dire linguaggio migliore, ed è questa la maggior critica che la gente fa del C++, più costrutti vuol dire linguaggio più difficile da usare, il che implica linguaggio che le persone usano male (francamente, quanti conoscono perfettamente il C++ e sanno usare tutti i costrutti ?), il che vuol dire scrittura di codice non facilmente mantenibile.

In questo il C è migliore, linguaggio più semplice, non semplice da usare ma che ha meno cose, più grezzo, ma le poche cose che ci sono chi scrive in C le conosce perfettamente e quindi sa come scrivere buon codice.

Gabriele Di Bari

Linus Torvalds oltre al C++ odia anche il Java (ancora di più del C++) e C# (in generale ha detto che OOP è una cosa stupida).
Ha anche dato delle motivazioni (alcune più che valide), ma diciamo che il tutto si riassume con: in C può vedere "mentalmente" esattamente il codice macchina che verrà prodotto cosa che non può fare con quest'altri linguaggi.

Gabriele Di Bari

Il C++ moderno è molto più moderno di C# o di Java.
di più moderno c'è solo Rust a mio avviso (bel linguaggio).
Concordo, se serve il C per un compito si usa il C e non il C++.
Ma certo non è una questione di performance.
Con C++ puoi ottenere le stesse prestazioni del C, se non maggiori (nel caso si imiti OPP con il C, in generale: se c'è una struttura del linguaggio che assolve a un problema, lo farà in modo più efficiente di quanto tu possa farlo), con un decimo del codice usando i template (il contro sono i tempi di compilazione).

Gabriele Di Bari

Non è che se compili direttamente del codice in Binario, ottieni le stesse prestazioni.
La GC rimane ;)

Gabriele Di Bari

Chi usa il C++ moderno, i raw pointer li usa una volta ogni morte di papa. Ogni linguaggio ha i suoi difetti, effettivamente C# ne ha di meno di altri, ma non è esule.
Il type deduction di C++ lo vorrei anche in C# ad esempio, o anche il argument matching di Rust .

Gabriele Di Bari

Non vedo come questo posta far definire Java un linguaggio poco prolisso.
Le lambda expression sono supportate anche da C#, ed ingenerale i delegate di C# (o le lambda function di C++) assolvono pienamente sia a le Anonymous Classes (as callback) che alle lambda expression di Java.
Indipendentemente da che piaccia o non piaccia, java tende a far scrivere più codice: assenza di macro, assenza di un sistema che permetta (attraverso i generic/template) la possibilità di espressione di tipo, enumerator con sintassi da pazzi, assenza di default parameters, mancanza di overload dei operatori, definizione di accesso per attributo/metodo da specificare ogni volta, gestione forzata e prolissa delle eccezioni, mancanza delle property, ecc...

C#Dev

Ma infatti io parlo della situazione attuale.

fabrynet

È un escamotage, la programmazione funzionale, per aggirare la rigida struttura della programmazione ad oggetti di Java. Un linguaggio fortemente tipizzato e molto rigido.

fabrynet

È un escamotage per aggirare la rigida struttura della programmazione ad oggetti di Java. Un linguaggio fortemente tipizzato è molto rigido.

Mako

Per quali motivi dovrei preferire C# a Java?

Mako

Con le lambda s'è ridotto molto il codice da scrivere

LoZio

Da quando hanno introdotto le lambda expression le cose sono migliorate abbastanza

DiRavello

beh swift ha tre anni di vita, dagli tempo

Paolo

Ognuno è libero di scegliere come farsi del male :)

Michele M.

Si hai ragione, chiedo venia. Purtroppo quella è roba che ho soltanto studiato e poco più. Ho sempre usato e lavorato con c++/c#..

manu1234

Beh dai, se cresce non sei l'unico ;)

fabrynet

Condivido su Java. Una sciagura.

fabrynet

La sintassi Java non è prolissa?

Giannarelli

ma qui solo io uso vb .net?

sickOfTech

Su un piedistallo non ci va nessuno, ma Java è un linguaggio ormai evoluto e completo (ha i suoi problemi), Swift ancora è all'inizio.

Aster

Infatti

ale

Sarebbe quasi da imparare il cobol, i pochi programmatori che ancora lo conoscono li pagano una fortuna

ale

C linguaggio funzionale ? Mi sa che hai le idee un po' confuse se confondi un linguaggio imperativo procedurale con uno funzionale

Aster

esatto

edge

Solo un appunto: avete descritto i Playgrounds come un giocattolo per bambini, ma sono uno strumento potentissimo per testare live snippet di codice e parti di interfacce grafiche. Specie nello sviluppare librerie esterne sono una vera manna del cielo, secondo me sono una vera killer feature di questo linguaggio.

ErCipolla

Rimango fedele a c#, ma devo dire che Swift sicuramente è anni luce avanti rispetto a quella porcheria di objective-c

Accapi

Su questo hai ragione!

Sagitt

ottimo!

manu1234

si sicuramente è più veloce di qualsiasi cosa, ma ad esempio, con il c++ non è tanta la differenza, e ormai per pochi euro hai processori che performano bene e consumano nulla, vedi raspberry pi 0

Michele M.

Hai numeri alla mano? Perché così a naso credo proprio che il codice scritto in c puro (e quindi un linguaggio funzionale e non ad oggetti) rimanga ancora ampiamente più veloce di qualsiasi altra cosa (asm a parte..)

Luca Lindholm

Comunque, la sintassi C#/Java è la migliore in assoluto.

A lungo andare, è quella che si ricorda meglio, non è troppo prolissa ed è molto versatile.

;)

ale

Perché per gli utilizzi di cui ti ho parlato, portano ad un overhead prestazionale sicuramente non da poco, e spesso rendono un progetto più complicato rispetto alla programmazione procedurale, fondamentalmente l'OOP va benissimo se lavoriamo con interfacce grafiche, con oggetti, ma per scrivere un kernel non serve a nulla e non solo nel incasina il progetto alla fin fine, oltre a ridurre le prestazioni ed occupare più spazio in memoria, e rischiare di fare errori di programmazione oltretutto (verificare la correttezza di un programma OOP è forse più difficile di un programma procedurale)

manu1234

ma perché nel 2017 non dovrebbero servire le classi? sono fottutamente utili, le hanno fatte apposta. io non faccio nulla senza classi

ale

Molti (incluso il sottoscritto ma incluso anche Linus Torvalds per esempio) preferiscono il C al C++.

Il fatto è che il C++ è un mattone difficilissimo da usare e da imparare, il C è semplice e permette di scrivere codice più pulito e soprattutto performante ed ottimizzato. Alla fine se non servono le classi, tanto vale usare il C, non ha senso il C++

manu1234

per non parlare del .NET native per compilarlo come fosse c++, classi interoperabili e molti più tipi primitivi. in ogni caso, si possono usare i puntatori in c# ma solo nei metodi unsafe

ale

C# è un incrocio fra Java e C++, senza le schifezze di Java e senza le schifezze di C++. Cioè hai alcune features del C++ (namespace, overload degli operatori, metodi virtuali o non, sintassi in generale per definire le classi per esempio) ma una filosofia come quella del Java (tutto è object oriented, garbage collector ovviamente, niente puntatori) con in più altre features comodissime tipo le proprietà (cosa che in Java manca e si sente, stare li a dovere scrivere metodi set e get è una rottura), i metodi async, e tutte le librerie del .NET che sono fantastiche

manu1234

si ma non ha senso essendoci il c++, che magari performa un po' meno, ma fa tanto di più

edge

Mio preferito, mi piace moltissimo, e ha un grande supporto fra la community. Certo, la ABI stability non è il suo forte XD

ale

Il C viene utilizzato ancora tanto oggi, perché semplicemente è ancora il più prestante e consente di interagire a basso livello come nessun altro linguaggio. Quindi si utilizza per componenti a basso livello del sistema operativo, per sistemi embedded (se devi fare un programma per un microcontrollore con qualche kB di memoria, non puoi usare altro ovviamente). Anche tutti gli interpreti ed i runtime di alto livello alla fin fine sono scritti in C, python, ruby, la JVM, il runtime .NET, sono tutti scritti in C, parti ad alte prestazioni di librerie ad alto livello, come moduli python per il calcolo scientifico tipo numpy che magari usano anche CUDA, hanno componenti in C, insomma è ancora usatissimo

Buon Compleanno iPad Air 2: 3 anni e come non sentirli con iOS 11 | Video

iPhone X, iPhone 8, Apple Watch 3 e Apple TV 4K #parliamone | Video

iPhone X ufficiale: dopo 10 anni Apple stravolge il melafonino

iPhone 8, iPhone X, iOS 11, Apple Watch e Apple TV: Live blog/video | Concluso