Intorno al 1980, ho preso una lezione di seminario in simulazione di eventi discreti da Nick Lawrence, che era il wizard di simulazione di eventi discreti di Texas Instruments. Li aveva salvati molti milioni di dollari, in un momento in cui un milione di dollari era ancora denaro reale.
Nick ci ha martellato su due cose, ancora e ancora e ancora.
Il primo era lo scopo. Cosa vuoi sapere? Perché stai facendo questa simulazione? Che cosa speri di imparare, a quale domanda vuoi rispondere? Se la tua simulazione non è impostata per rispondere a queste domande, o se è fisicamente in grado di rispondere ad esse in un certo modo, ti stai prendendo in giro e stai danneggiando te stesso oi tuoi clienti, molto male.
Il secondo era la convalida. Come fai a dimostrare che la tua simulazione simula in modo preciso ciò che vuoi simulare? Se la tua sim non è del tutto corretta, WILL ottieni risposte sbagliate.
Il classico esempio di fallimento della validazione è TTAPS " Inverno nucleare ". I progettisti sim convalidarono le loro sim contro i dati marziani, dimenticando che la Terra, a differenza di Marte, aveva oceani e coste e neve con effetto lago. Dopo che avevano pubblicato, qualcuno ripropose la simulazione con quegli effetti, e scoprì che la neve ad effetto lago puliva la polvere dall'atmosfera in circa un anno. (Qualcosa di simile è accaduto nel 1800-E-Froze-To-Death, L'anno senza estate.
Quello su cui sto guidando è questo: finché non puoi dire ciò che vuoi imparare e come prevedi di convalidare la tua sim, la scelta del linguaggio di programmazione NON è ciò a cui dovresti pensare.
C'è un terzo punto che dovrebbe essere sollevato, quello della scalabilità. Finché non puoi simulare il tuo sistema con una manciata di nodi, CORRETTAMENTE, e ottenere le risposte che ti servono sul modello piccolo, non ha senso cercare di simulare migliaia di nodi.