Why I Will Not Use Java

This post is quite old. I wrote it back in 2010, when I realized Java's main drawback is its verbosity. I didn't expand my thoughts, 'cause I was too engaged at work with C, Objective-C and Python. But in these days I read some articles about Java 8 and I felt very disappointed, 'cause it lacks some features, some snippets and doesn't resolve Java's main drawbacks.

Java Language is Verbose

Java Language is verbose, in the worst way you can say it, mainly for two reasons.

Lua vs Python or Embedding vs Extending

Another (in)famous comparison!

At least once in your programmer career, you will face the need to add a scripting language to your program. Many famous programs use a scripting language: Unreal, Quake, Emacs, Blender 3D and many games. But, when you decide it and when you start to project your implementation, you face a terrible dilemma: should you make a program with a interpreter or functions for a interpreter? This crossroad is the "embed vs extend". I'll talk about my personal opinion and how this dilemma is equal by Lua vs Python comparison.

iPhone SDK Troubles: a missing feature in XCode 4

XCode4.0.2 hasn't got a "Search and Replace in Selection" tool. It's one of most important tools for some very boring tasks, such as adding a @synthesize to hundred of lines or using the same lines to initialize them with a [[NSString alloc] init];
I hope Apple soon adds it: I wouldn't to continue switching between XCode and VIM to replace some text!

Nobody can choose how to trash

Today I read an interesting letter sent from Ted Evans of Techrunch to Steve Jobs. He said


Please give us garbage collection



When you say "garbage collection" you always think to Java, to its slowness and to its inefficency. I think, instead, about days spent to detect a memory-leak error, when I was near to the deploy deadline. Working with iOS is wonderfull, but can also gives you headache if you aren't enough careful. Useless to say, when you have to realize a 4000-rows-of-code in two days, it's hard to be "enough careful"!

Ok, I admit a garbage collector could makes programs slow. But if I could use it when I want and if I could dealloc objects when I want, I could realize a "slow" version in time. Slow as you want, but it will not crash because of memory overflow, segmentation faults, ecc.
In next version, with more time, I could analize the code, optimizing memory use and detecting overflows and errors.
So, yes: I would like a Garbage Collector. But activable only when I want.

PS:
Can you recognize the man on the "wanted" poster on this TechRunch article? Well, our prime minister (I am italian) isn't very admired in other countries

The answer to a Non-Rigid-Organization

Japanese philosophy is so near to computer-science

Do you remember? Some days ago I suggested some ways to do data-entry, but I didn't explain well when a wiki is a good solution. I want to illustrate better this concept and introduce you some cases where a wiki is a comfortable solution.

Wabi-Sabi

What's Wabi-Sabi? In wikipedia we read

Wabi-sabi (侘寂?) represents a comprehensive Japanese world view or aesthetic centered on the acceptance of transience. The aesthetic is sometimes described as one of beauty that is "imperfect, impermanent and incomplete".[1] It is a concept derived from the Buddhist assertion of the Three marks of existence (三法印 sanbōin?), specifically impermanence (無常 mujō?).
Characteristics of the wabi-sabi aesthetic include asymmetry, asperity, simplicity, modesty, intimacy and the suggestion of natural processes.

Do this sounds familiar to you? Concepts like "transience", "impermanence", "incompleteness" can appear very often in a bad organized office and are programmer's hell. Let's think to write a relational database. It's well designed and has good interfaces for CRUD. Now, let's imagine our boss asks us to change the relational schema. Adding or removing a column could be not very difficult, but changing big pieces of this schema means to rewrite our application controller from 40% to 70% and write some scripts to move datas from the old schema to the new. Pretty boring and frustrating. And, more important, probably non definitive, because in a bad organized office, changes could happen very often.

Wiki is Wabi-Sabi

A wiki is "fluid". It have a very simple schema (to our eyes), mostly based on "Articles" and "Categories". It checks if a certain page exists (blue links) or not (red links); it lists all uncategorized pages; it lists all unused categories, ecc. It will also include the "Search" which shows us all pages wich contain the searched word.
I choose a wiki for a particular job: I had a web application and I have to list all entities showed to the user. I started with an excel spreadsheet, listing where the entity was located (in wich web page), if it was read or write, who can modify it and other fields. This organization changes some days ago, forcing me to change the schema. But this time I moved all data to a wiki (mediawiki), making a page (article) for every entity.
Result: it's appreciated and a change will be managed easily, 'cause there's no SQL schemas to modify, just pages.
If you're losing your life on a Access database and your boss wants every day a "small change" which makes you mad, then moving to a wiki is probably the best solution.

Never do Data-Entry

«I am sorry if I didn't write these days. Unluckly, I was very busy with a lot of work so I didn't pay much attention to other tutorials. Excuse me. I'll try to write something about next week»

It happened to me yesterday...

Data Entry is bad by design.
It's true, it's important, because without datas, a database is useless. But there are good and bad ways to insert datas. Good ways are:

1. User-Based: users insert informations on specific designed application
2. Data-Transfer: datas are moved from a data source (text file, excel, network, ecc.) to a destination database with a script
3. User-Evolved: it's similiar to the user-based. It's more Zen, because in this model we admit «perfection is impossible, imperfection is normal, evolution is required». Premising we can't insert all datas, we'll delegate users to modify and to refine them. It's how Wikipedia works

Bad ways are (usually) more widespread, because data-entry is made to solve an informations hole without considering how the database will evolve, who will use it and how.

1. One-Man-One-App: this is the "less worst" solution. A programmer is charged to implement a program to manage a database and to fill this database by himself. Though is still a bad solution, it's a bit more human because the programmer can write a program more suitable for HIS needs. More important, a single error doesn't compromise whole work
2. Data-Source-Based: absolutely THE worst solution. Two or more users work to fill a common data-source (an excel file, a text file, ecc.)

One-Man-One-App problems are:

1. A new "data-inserter" must be trained to learn how the hight-customized application works
2. Move datas to another database more well designed could be difficult
3. The official data-inserter doesn't always pay necessary attention on data-entry, because he's a programmer. Repetitive jobs make programmers angry and frustrated

Data-Source-Based is bad because

1. Data-entry manifests in its worst way: "filling" an excel spreadsheet is one of most boring and frustrating activities on earth. Even a 100x6 table is hard to fill with care
2. "Save button" is "Cumulate-and-Fire" anti-pattern incarnation. If someone forgets to Save, hours of works could be trashed
3. Finding errors could be hard if you have more than 7 columns
4. A clumsy operation (e.g. a "sort and save" just on a selection) could make datas inconsistent and ruin irremediably all the work done

If you're ALONE to fill a large database with datas wich came from paper or other non-scriptable sources, try to move yourself to a good way of data-entry. If it's impossibile, NEVER USE data-source-based: create a front-end even if you're working with an excel. This will allow you to have to avoid the "cumulate-and-fire" anti-pattern, will allow you to make a more comfortable way to insert datas and will give you a little fun when coding your script.

Anyway, data-entry is bad and boring. The only good way to do it is spreading it among three or four employed on a long timeline. 10 minutes per-day of data-entry is sopportable: two or more hours per-day doesn't.

Meanwhile, in Microsoft Russia...

In USSR, Windows installs you

Nikolai Pryanishnikov, Microsoft Locale Director in Russia, says that

«We must bear in mind that Linux is not a Russian OS and, moreover, is at the end of its life cycle»

I am a bit disappointed by this statement: I always belived that Microsoft managers were smart enough to avoid some hazardous declarations. Says that «Linux is dieing» is a manifestation of ignorance.
Actually, GNU/Linux is a player to face in important environments such as

• Embeded devices
• Servers
• Mobile phones with Android

I suppose mr. Pryanishnikov was talking about the desktop market, but he must understand that HIS statement is offensive for HIS company.
As president of Microsoft in Russia, Nikolai Pryanishnikov hasn't capacity to say everything he wants: he have to think well what he can he says and what he can't. A misunderstanding in business world can move billions of dollars. A good CEO will take the situation in his hands, to correct this clumsy sentence.
Mr. Pryanishnikov misses to report citations and, more important, to say something about the Google OS. It's right that it's not yet released and that its base (Google Chrome) is just at 8% of broswer market shares (source: Wikipedia). But wait: Android is at 25%, while Windows Phone is at 3% (source: Wikipedia) and mobile market is becoming more important than ever. If Mr. Pryanishnikov was a smart president, then he would know that HIS Chief Software Architect (Ray Ozzie) sent a memo less than a month ago where he talked about the new marked trends (mobile, cloud computing, ecc.). Ignore what says your Chief Software Architect is clearly self-defeating.
If GNU/Linux's zealots are annoying, then Microsoft's supporters aren't better. But a fanboy's rant is forgettable; a manager's rant in public is not.
Mr. Pryanishnikov must think very well where, when and what he says, giving some attention to the same market shares I found googling some minutes. If I can do, then he can too.

Buy now your new iBrick!

Think heavy

A news from Ars Technica

«[...]Biana Wofford alleges that Apple purposely crippled the iPhone 3G with its introduction of iOS 4 in order to boost iPhone 4 sales[...]»

I am (for work) a iPhone 3GS user. I like my phone, it works well and it has a large application store. ACTUALY I haven't troubles with my iPhone. But last Apple politics doesn't calm me down. When I bought my Macbook Pro I was convinced I could buy another PC after five or six years, maybe even more. I'm still convinced this is true, because Apple's tight integration between hardware and software is good. But his "tight integration" is becoming a hell on iOS devices.
Building a software good for a Mac G4 and a Mac-Intel isn't easy. Anyway, if I should have Mac G4, I will probably accept it's slower to launch a program than a new Mac-Intel. But a smartphone isn't a computer and it has a completly different "way of mind": when I compose a number, if I have to wait three seconds, I think something is going wrong; if I see a delay when scrolling my contacts list, then I think there's too many processes in background.

Apple forbids iOS downgrade to prevent users to pass to a jailbreakable version. I can understand this. But I can't understand how Apple can pretend that a user gently accepts to choose between a unusable "brick" or 500$ to buy a new iPhone 4. I can understand that supporting patches for three or four iOS versions (e.g. 2.x.x, 3.1.x and 4.1.x) to grant a unbreakable OS for different hardware isn't easy neither cheap. But these solutions aren't well accepted.
After the drop of XServe line, I expect more attention on its consumer products.

Stop smoking

Wanna try to stop?

I'm thinking about my Facebook page. What I found there? Some interesting news (in Italy a politician, Nicky Vendola, updates his status at least two times at day). Some news posted by me (mainly blog uploads and shared links). And a lot of (useless) status uploads and a lot of not very interesting news (some are near to spam). I start thinking to unsubscribe from the "Blue Social Network", because all interesting news can be found with a good RSS reader, but soon I realize I can't.
Facebook isn't a "funny site" anymore: it's the "main street" of internet comunication. Your Facebook page is your business card to the world, more than your blog or your web site. It's the best place to put your advertising, 'cause it will be sent to all your Facebook contacts.
You ARE your Facebook page; you ARE the news you post and the links you share. All these informations draw your profile to the other Facebook users.
When someone is looking for you, he will go to Facebook. I can survive without Facebook, using just iChat connected to Facebook's jabber server; but all other social activities (publicize a movie, a post on my blog or just share a newspaper article) can be done only with Facebook.
Facebook is a powerful tool, but for some days I felt sad on last sessions. Why?
My answer (just my 5 cents) is simple. I feel like when I tried to stop smoking: I felt strange some days because I didn't know what to do. Smoking was like a "filler", a way to don't get bored while I didn't any activity.
When you're on a boring office, with no chance to talk about interesting things with your colleagues, what can you do? Connect to the blue site.
Well, I decide to stop "facebooking" with no reason. I stop using it with a precise idea about what to do in it: no "busy wait" for a chat, not looking all 200 demotivational posters 'cause I don't know what to do. I'll start to use it conscientiously, as the last BBSs' offspring.

PostScriptum
Take a look to this old soviet device. It was created three years before Photoshop 1.0. Interesting :)

La trappola del C++ (quarta parte)

Bjarne Stroustrup, l'autore del linguaggio C++

Nei precedenti post ho illustrato le difficoltà che possono emergere dall'uso del C++ e gli eventuali correttivi. Nell'ultimo post avevo accennato alla domanda «ma abbiamo ancora bisogno del C++?». Contrariamente alle previsioni, la mia risposta è «si, ne abbiamo ancora bisogno», ma con le dovute attenzioni.
Lo scopo dei miei post non è mai stato denigrare il linguaggio di Stroustroup, ma sottolineare come alcune posizioni di principio facciano più male che bene.
Pensate a un programma come Gwibber: è un programma di microblogging che aggiorna il vostro stato su Facebook e su Twitter (lo facesse anche su Google Buzz sarebbe perfetto); è veloce e pratico. In che linguaggio è stato scritto? In Python puro, con le interfacce grafiche fatte con le GTK+ per integrarlo nell'ambiente Gnome. Avrebbe avuto senso scriverlo in C++? Non penso. Non ne vedrei l'utilità. Il programma funziona e fa quello che deve fare senza rallentamenti né noie.Avremmo aumentato il numero di righe di codice (sicuramente di un buon 30%) per guadagnare qualche millisecondo che, per quello che deve fare Gwibber, sarebbe stato inutile.

Ma me serve il C++!
Analizziamo, invece, Vuze, noto client BitTorrent. Lo uso spesso, funziona ed è ricco di funzionalità. E' scritto in Java e su un sistema un po' datato non da un'esperienza utente particolarmente gradevole. Varrebbe la pena riscriverlo in C++? Non saprei, ma sulla pagina wikipedia dedicata ai client bittorrent ne trovo almeno tre (uTorrent, Opera e KTorrent); altri sono scritti in Python; uno solo in C#. Evidentemente Vuze non è particolarmente amato dall'utenza.

Mettiamo a confronto due programmi simili, ossia due motori 3D: il Source della Valve e l'Unreal Enginedella Epic Games. Non ci sono storie: entrambi DOVEVANO venir scritti in C++ (persino John Carmack, il programmatore eroico che ha scritto Quake 2 in puro C, per Quake 3 s'è votato al C++) perché un motore grafico 3D ha bisogno di

1. Massima velocità di esecuzione, perché qualche millisecondo può far la differenza
2. Alto livello di astrazione, visto l'alto numero di entità coinvolte
3. Contatto il più vicino possibile con l'hardware della macchina
4. Rispetto delle deadline nel contesto realtime

Python non è in grado di far questo e Java nemmeno. In questo contesto il C++ è davvero l'unica scelta praticabile. I programmatori dell'Unreal Engine, però, si son dimostrati più furbi di quelli di Valve. Unreal Tournament 2003 è stato fin da subito disponibile per Mac OS X e GNU/Linux, mentre Source no. Come mai? Alla pagina di wikipedia c'è la spiegazione, ma se siete stati attenti negli articoli precedenti avrete già indovinato. A un engine di base fatto in C++ facilmente portabile, i programmatori di Epic hanno agganciato un motore di scripting (UnrealScript) che gestisce tutta la logica di gioco. Per loro è "bastato" (le virgolette sono d'obbligo) riscrivere alcuni blocchi di basso livello (routine grafiche,audio) per trasferire un intero gioco su altre tre piattaforme. Source, invece, ha tutti i plugin scritti in C++ e compilati all'interno del motore. Fare una modifica su un programma del genere (in questo contesto ci aggiriamo facilmente sulle 20.000 e più righe di codice) non è assolutamente un lavoro da poco.

La Valutazione dei Requisiti
Sul famoso racconto «La notte che bruciammo Chrome», William Gibson racconta la storia del miglior colpo fatto da due hacker: questi due vivono in condizioni economiche pietose e vogliono fare "il colpaccio". La svolta avviene quando uno di loro scopre che un misterioso cubo comprato al mercato nero è un sistema di intrusione informatico pensato per i militari. Ma, anzichè esultare, il personaggio dice

«Mi sentivo come il ladruncolo che scende in strada per comprare un coltello e torna a casa con una bomba a neutroni. Tombola. Cosa te ne fai di una bomba a neutroni in una rissa di strada?»

Riuscite ad afferrare l'analogia? Il C++ è la bomba a neutroni. E' vero che col C++ si fa tutto, ma pochi ci mettono davvero la testa quando programmano in quel linguaggio. Provate a pensare ai programmatori C++ che conoscete e chiedetevi:

• quanti hanno parlato di aver scritto una classe String più efficiente?
• quanti hanno detto di aver pronta una personale libreria di template?
• quanti hanno scritto delle classi per la gestione delle strutture dati comuni (vettori, liste)?
• quanti hanno riempito di cout<< i loro programmi?

Ora, per contro, pensate a quanti

• hanno scelto un motore di scripting interno?
• hanno fatto una valutazione dei requisiti?
• hanno calcolato le deadline del programma?
• hanno utilizzato lo GNU debugger?
• hanno utilizzato software come Valgrind?
• hanno utilizzato le librerie QT?

Qui son stato volutamente provocatorio, ma il senso è chiaro. Molti decidono di programmare in C++ per partito preso, senza considerare se hanno davvero bisogno dell'astrazione, della velocità (e delle difficoltà) proprie di questo linguaggio. Lanciano allegramente g++ senza riflettere seriamente su debug, gestione della memoria, portabilità e su tutti i problemi di cui ho parlato. E' un po' come vedere il ladruncolo che armeggia con la bomba a neutroni dicendo «funziona meglio di un coltello, ne minacci di più e so perfettamente come funziona»

Pensare a un roguelike

Agband (immagine hostata da Wikipedia), uno dei roguelike più famosi

Faccio un altro esempio: provate a progettare (solo progettare) un gioco sullo stile di Angband. Questo tipo di giochi si chiama roguelike e sono degli RPG, generalmente basati sul regolamento di Dungeons and Dragons. L'interfaccia, come vedete, è scarna da far paura: è un'interfaccia a caratteri che usa i caratteri come tiles e come sprite.
I requisiti di questo nostro roguelike sono:

• mappe caricate da file (non è molto "rogue", ma è per semplificarvi la vita)
• movimento all'interno di mappe più grandi dello schermo
• salvataggio e caricamento delle partite
• gestione delle caratteristiche del personaggio
• gestione degli oggetti di gioco (armi, cartelli, pozioni, ecc.)
• Intelligenza artificiale dei mostri

 Provate a pensare a cosa significherebbe programmarlo in C++ su Ubuntu. Terminatolo, provate a pensare di farne la conversione in C++. Pensate a come evitare i memory leak e le ricerche fuori da un array. Pensate a riscriverlo in un altro linguaggio (Java, Python, Ruby... fate voi). Vi garantisco che le performance non se risentiranno, ma il tempo di sviluppo si (e anche tanto).

La Conclusione
Il C++ è nato con l'obiettivo di aggiungere le classi al linguaggio C mantenendo alta la velocità di esecuzione e la compatibilità con l'illustre predecessore. E' stato impiegato in quasi tutti i grandi progetti software dal 1995 in poi (Autocad, Quake 3, KDE...) e i suoi meriti sono indubbi.
Lo scopo di questa serie di articoli non è mai stato dire "il C++ fa schifo", ma invitare chi inizia a fare un progetto a chiedersi se valga davvero la pena affrontare anche tutte le problematiche che lo sviluppo di un programma C++ richieda.
Se poi i requisiti sono tali per cui  non si può davvero fare a meno del C++, è stata mia intenzione rivolgere l'attenzione del lettore al debugger, uno strumento utile che viene sottovalutato in diversi ambienti, ma che è un compagno inseparabile di chi lavora con i linguaggi compilati.
Del C++ non ci si sbarazzerà facilmente: la sua ubiquità, velocità di esecuzione e astrazione sono necessari in una miriade di contesti (videogames, sistemi realtime, controlli hardware, ecc.): ma la presenza di altre soluzioni software (Python, Ruby,Java) deve spingere lo sviluppatore a fare delle buone analisi e vedere cosa effettivamente vuole ottenere.
Analisi, pochi pregiudizi e attenzione.
E buona programmazione!

Note
Un paio di link utili come spunto per ulteriori riflessioni

• Il (tristemente) famoso post di Linus Torvalds sul C++
• Una risposta a quel post
• La pagina del GNU Debugger
• La pagina del progetto Valgrind

 All'anonimo autore del "provocatorio" commento (che ho apprezzato ;) ) dico che mi ha dato una bella idea per un prossimo post su Java.

La trappola del C++ (terza parte)

Nel procedente post ho mostrato come scrivere un programma in C++ che soddisfi il requisito della portabilità sia un compito più arduo di quanto si possa credere. Tuttavia molti programmi (come Blender 3D e Mozilla Firefox) sono stati portati con successo su diverse piattaforme.
Il segreto di questi programmi è relativamente semplice: i programmatori hanno costruito una solida e veloce base in C++ cui hanno agganciato l'interprete di un linguaggio di scripting (python nel caso di Blender 3D e XUL per tutti i prodotti di Mozilla). Una volta testato che la base C++ è robusta, tutto il resto è script. Se una funzione è troppo lenta la si riscrive in C++, ma tutto il resto rimane immutato e funzionerà su qualsiasi piattaforma. Se c'è un errore nella logica di programma probabilmente è all'interno di uno degli script: in questo caso è molto più comodo correggere uno script, piuttosto che ricompilare qualche mega di sorgente, non trovate? Lo stesso dicasi nel caso si voglia aggiungere una funzionalità: si scrive un file e lo si sposta nella cartella degli script.
Nel mondo dei videogame c'è un illustre esponente di questa tecnica: Quake 2, che John Carmack scrisse in puro C e che dotò di un motore di scripting scritto apposta per tutta la logica di gioco.
E nel free-software? Qualcuno conosce un altro programma che segua questa filosofia? Un applauso per chi ha detto EMACS.

fig 1

A questo punto dovrei parlare della gestione della memoria, croce e delizia del programmatore C.
Qua apro una parentesi di storia personale: spesso ho trovato persone che si son lanciate entusiaste nel famoso discorso "C++ è figo, Java è uno schifo". Di tutti questi, solo uno è riuscito a finire un progetto (circa 10.000 righe di codice) e ha passato le notti sul debugger per trovare le istruzioni delete che mandavano in crash il programma. Questo perché bisogna far ben attenzione a quando invocare una delete.
Prendete, ad esempio, il grafico riportato in Figura 1.

In questo quadro, la classe Camera ha richiesto a MediaCache un oggetto di tipo Image. Per comodità, di questo oggetto abbiamo passato il puntatore.

Immaginiamo, ora, che il programmatore diligente lanci una delete appena Camera ha terminato di usare l'oggetto ImageToDisplay. Il risultato è che anche l'elemento dell'array di MediaCache punterà a niente, con risultati disastrosi (Figura 2).

fig 2

Objective-C risolve il problema utilizzando oggetti che tengono il conto del numero referenze che puntano a essi utilizzando i metodi retain e release. E' molto bello come sistema, e vi consiglio di dare un'occhiata alla sezione sette del Cocoa Dev Central e alla Figura 3.

fig.3
In Objective-C, si va a liberare lo spazio solo
quando il contatore delle referenze va a zero

Certo, il caso del motore grafico 2D è estremamente semplice e si può facilmente capire cos'è che va storto. Ma provate a fare il debug in un contesto di più seimila righe di codice e perderete sicuramente qualche oretta nel capire come mai il programma da segmentation fault.
Alcuni programmatori C++, sapendo che avrebbero potuto dimenticare qualche delete (in programmi lunghi milioni di righe di codice è una svista inevitabile), risolvevano il problema con un'area tampone d'emergenza, ossia:

1. All'inizio del programma, come prima cosa, si alloca 1 Megabyte di RAM a vuoto (puntato da char* help_buffer;)
2. Ad ogni new, si va a verificare che il risultato sia diverso da NULL. In caso contrario, c'è stato un errore di memoria: probabilmente i memory leak hanno saturato la memoria e rendono impossibile qualsiasi altra operazione.
3. Si dealloca lo spazio puntato da help_buffer. Si libera così abbastanza memoria per resettare tutto il programma e, nel peggiore dei casi, a riavviarlo.

La soluzione è brutta, è poco elegante, ma in contesti critici (server, per esempio) garantisce che il programma continui a girare ininterrottamente. Immaginate un server web che va si pianta una volta al giorno:.i sistemisti non vi ringrazieranno per la straordinaria velocità e vi malediranno per la scarsa affidabilità. Il debug, le limature e la raffinazione del programma si farà poi, la priorità è che il programma funziona ed è affidabile.

Se programmate in C++ non sottovalutate MAI il debugger: è il vostro migliore strumento e più fido alleato. Evitate di ricorrere sempre ai cout<< di variabili. Sono utili per avere il log di sistema e per aiutare voi e gli utenti a fare un bug report. Ma un buon debugger vi servirà a capire precisamente cos'è andato storto: una delete azzardata, una new andata male o una ricerca all'interno di un array vuoto vengono facilmente individuate da un debugger.

Conclusioni
Se state programmando in C++, senz'altro avrete bisogno di un debugger. Se state programmando in C++ fate molta attenzione alla gestione della memoria: individuare i memory leak e i crash dovuti a maldestre free è difficile. Se in fase di progetto vi accorgete che il programma inizia ad essere davvero complicato, valutate se è il caso di utilizzare un linguaggio di scripting al suo interno.
Nella prossima parte, concluderò questa serie di articoli rispondendo alla domanda «ma abbiamo ancora bisogno del C++?»

(continua nella domani nella quarta e ultima parte)

La trappola del C++ (seconda parte)

«Non è facile portare un satellite in orbita»
Lo Space Shuttle Atlanits (STS-27)
Immagine fornita da Wikimedia Commons

La trappola del C++ (prima parte)

Il titolo è provocatorio, lo dico subito. Se pensate che qualsiasi programma è meglio scriverlo in C++ dimenticate l'esistenza di questo post, visto che vi farà solo venire acidità di stomaco.

Se, invece, siete disposti a in discuterne, mettetevi comodi: ci sarà da divertirsi.