Articles in category: Functional Programming
Objective-C is not going anywhere. While Swift is most certainly the new hotness for iOS and OS X programming, there are some concrete reasons to stick with Objective-C for a while:
- Objective-C based projects still need maintenance and new features to be added, and mixing Swift and Objective-C, while possible, can be tricky and possibly unconvenient, due to the dynamic nature of the latter;
- Swift is changing rapidly, has still some bugs and performance problems, and still lacks some features that professionals need, while Objective-C is mature and has a strong community;
- some may prefer a more dynamic language, and Objective-C support from Apple is still strong;
Personally, while I naturally lean towards a more static, type-first approach to programming, from time to time I like to work in a more dynamic environment, so both for preference and for business needs, I still didn’t put Objective-C completely away. But just after a few weeks of Swift I found myself missing one of the most powerful features of the language: Optionals.
Objective-C vivrà ancora per molto. Nonostante Swift sia il nuovo punto di riferimento per lo sviluppo iOS e OS X, ci sono ragioni concrete per scegliere di continuare a sviluppare in Objective-C, almeno per un po':
- progetti esistenti basati su Objective-C richiedono ancora mantenimento e probabile aggiunta di nuove funzionalità, e anche se è tecnicamente possibile mescolare i linguaggi, la cosa può risultare poco conveniente per via della natura molto dinamica di Objective-C;
- Swift sta cambiando rapidamente, presenta ancora alcuni bug e problemi di performance, e il suo workflow manca ancora di alcune feature fondamentali per i professionisti, mentre Objective-C è un linguaggio maturo, con una community molto vivace;
- alcuni possono preferire un linguaggio più dinamico, e il supporto di Apple su Objective-C è ancora forte;
Personalmente ho la tendenza a preferire linguaggi più statici, e un approccio type-first alla programmazione, ma di tanto in tanto mi piace lavorare in un ambiente più dinamico, quindi, sia per preferenza personale che per esigenze di business, non ho ancora messo Objective-C da parte. Ma dopo poche settimane di Swift, mi è mancata subito una delle sue funzionalità più potenti: gli Optionals.
There is an unwanted guest with us as we write code and build software projects: it’s the code that’s already written, and we must take into account its complexity as the code base increases in size. High complexity of the existing code can make the following activities particularly difficult:
- understanding the meaning of old code, written by others or ourselves;
- tracing the causes of bugs, i.e. errors, in code;
- making changes to a certain procedure;
- adding features to existing structures;
Even if we approach the development of new software with agile methodologies, we always have to deal with the existing code, and to do that we must at least be able to understand it without overexertion. So when I talk about complexity I am referring in particular to the difficulty with which a programmer can reason about the existing code: the preface of the well-known academic textbook Structure and Interpretation of Computer Programs contains the following sentence:
C’è un ospite indesiderato che ci accompagna sempre mentre scriviamo codice e realizziamo progetti software: si tratta del codice già esistente, e dobbiamo tener conto della sua complessità man mano che la code base aumenta di dimensioni. Un’elevata complessità del codice può rendere le seguenti attività particolarmente difficili:
- comprendere il significato di codice vecchio, scritto da altri o da se stessi;
- tracciare le cause di bug, cioè errori, nel codice;
- eseguire modifiche a una certa procedura;
- aggiungere funzionalità a strutture già esistenti;
Anche approcciando lo sviluppo di nuovo software con metodologie agili, dobbiamo comunque fare i conti con il codice esistente, e per farlo dobbiamo almeno essere in grado di comprenderlo senza sforzi eccessivi. Dunque quando parlo di complessità mi riferisco in particolare alla difficoltà con la quale una programmatore è in grado di ragionare sul codice. La prefazione del noto testo accademico Structure and interpretation of computer programs contiene la seguente frase:
Nel suo discorso di accettazione del Premio Turing 1972, dal titolo “The humble programmer”, Edsger Wybe Dijkstra, uno dei più celebri computing scientists del 20° secolo (morto nel 2002), affrontò le cause della nota Software Crisis, cioè la crisi che colpì l’industria del software nella seconda metà degli anni sessanta: la potenza e la capacità di elaborazione dei computer stavano crescendo esponenzialmente, molto più rapidamente dell’abilità dei programmatori di gestire la complessità e scrivere software funzionante. Nello stesso discorso, Dijkstra propose anche delle possibili strade da intraprendere che a suo avviso avrebbero portato aziende e università a migliorare la qualità del loro software. Riporto qui una frase che a mio parere riassume abbastanza bene l’intero discorso:
