Per cel·lebrar el nou canvi a la web, us poso una traducció que vaig fer fa temps i que havia de revisar, però mentre la reviso, podeu fer-hi una ullada.
Es tracta d'una de les meves paranoies que tenia pel cap des de fa uns anys i que per casualitat, fa mig any vaig trobar que hi ha gent que també té els mateixos problemes mentals que jo. I, és agradable, comprovar que arriben a les mateixes conclusions que jo, i fins hi tot algunes més que ni m'havia plantejat, a part d'organitzar aquestes idees i plasmar-ho en un document.
L'article està en anglès, i com que el meu anglès és limitat, vaig tenir que traduir-lo. L'enllaç original és aquest: http://users.adelphia.net/~lilavois/Cosas/Reliability.htm. Ara mateix, però, també hi he trobat altres referències, així que com que no sé quina és la original també les poso: http://pages.sbcglobal.net/louis.savain/AI/Reliability.htm
La Bala de Plata (La Solució Definitiva)
Perquè el Programari És Dolent i Que Podem Fer per Aturar-ho
Abstracció: Hi ha quelcom en la manera en que creem programari que està mal fet. Aquest article proposa una solució de "bala de plata" al problema de la confiabilitat i la productivitat del programari. La solució requereix un canvi fonamental en la forma en que programem els ordinadors. Parlaré que la raó principal que el programari no sigui fiable i difícil de desenvolupar té a veure amb un costum tan vell com l'ordinador: la pràctica d'utilitzar els algoritmes com a base per la construcció de programari. Aniré més enllà de canviar cap a un model pur basat en senyals, el model de programari sincron produeix com a mínim una millora en la magnitud de la confiabilitat i la productivitat.
El Programari És Dolent i Obtindre el Pitjor
El Síndrome "Cap Solució Definitiva"
No fa massa, en un article (pdf) sobre la crisi a la confiabilitat del programari publicada pel MIT, l'autor dona tota la culpa del problema als programador pels plantejaments dolents i les desicions econòmiques. La solució proposada: dur-ho als adbocats. L'article no va fer menció a quelcom tan fonamental com la mala forma en que desenvolupem el programari. La raó d'aquesta omisió té a veure en part amb l'escrit altament influent titulat: "cap solució definitiva -- l'esencia i els accidents de la tecnologia de dotació lògica" que fou publicada el 1987 per un famós informàtic anomenat Frederick P. Brooks. El Dr. Brooks escriu:
Però, així com mirem a l'horitzó de fa una dècada, no veiem cap solució definitiva. No hi ha un únic desenvolupament, en la tecnologia o en la tècnica de la gerència, que per si mateix iguali la promesa d'una millora en la productivitat, la confiabilitat i la simplicitat.
...
No només ara mateix no hi han solucions definitives a la vista, sinó que la mateixa naturalesa del programari fa inverosimil que hi hagi -- cap invenció que ho faci per la productivitat, la confiabilitat i la simplicitat del programari com l'electrònica, els transistors, i la integració a gran escala o hagin fet pel maquinari.
Cap altre escrit en la història de la tecnologia de dotació lògica ha tingut un efecte més perjudicial en els esforços de la humanitat per trobar una solució a la crisis de la confiabilitat del programari. Casi sense ajuda, va tenir èxit en el convenciment de tota la comunitat de desenvolupament del programari que no hi ha esperança per intentar trobar una solució. És un capítol quelcom desafortunat en la història de la programació. Els deu mil milions de dòlars i fins i tot les vides humanes que s'han perdut i es perdran com a conseqüencia d'això.
El cridar els adbocats i donar feina a més experts en programari ensenyats sota un paradigma antic no solucionaran el problema. Serà solsament més costos (els adbocats, els experts i els enginyers entrenats no treballen a canvi de monjetes) i, al final, més mortal. La raó és triple. Primer, la complexitat i la ubicuitat del programari continuent creixent sense control. En segon lloc, l'amenaça de pleits significa que s'elevarà de cop i volta el cost (temps i diners) del desenvolupament de programari. Tercer, les mesures transitories incrementals oferides pels experts no es dissenyen per arribar al cor del problema. Es dissenyen per proporcionar la sortida ràpida al problema a expenses de mantindre als experts en plantilla. A mitjà plaç, la crisi continua.
Per qué un paradigma antic? Perqué la causa d'arrel de la crisi és tant vella com la senyora Ada Lovelace i Charles Babbage de la fama analítica del motor, com explico més avall.
Perqué Els Experts Estan Equivocats.
Interes adquirit
Els experts de la confiabilitat del programari (tals com la gent de Cigital) tenen un interés adquidit en que la crisi duri tant com sigui possible. És la seva raó de ser. Els informàtics i molts programadors estimen les idees de Brook perqué una crisi insoluble del programari els proporciona una feina ben pagada i una carrera de per vida com a enginyers de confiabilitat. No és que aquesta gent no aportin millores de mèrit en el tema. Ho fan. Però buscar una solució que dugui la millora de confiabilitat i productivitat del Dr. Brook no està en la seva agenda. Neguen, fins i tot, que aquesta fractura sigui possible. L'escrit d'en Brook és el seu Nou Testament i "cap bala de plata" (solució definitiva) els seus sequit. El pitjor de tot és que la majoria d'ells estan segurs de les seves conviccions.
La majoria de la feina d'ara per assegurar la confiabilitat del programari s'esta soportant completament sobre les espatlles del programador. Una industria sencera de la confiabilitat ha brollat amb incontables experts i venedors de la eina amb varies receptes, teories i pràctiques depenents de la feina de la enginyeria. Però després de més de vint anys que la gent va començar a parlar del problema co a crisis, és pitjor que mai. Com apunta l'article "Revisió de la Tecnologia", el cost s'ha anat incrementant.
Al cap i a la fi, hi ha una solució definitiva
Els cervells del essers humans i dels animals són la prova de la existència d'una solució definiva. La robustesa i la confiabilitat es mesuren amb la relació de la complexitat entre els defectes. Degut a la seva complexitat astronòmica, el cervell humà és el sistema complexe més confiable del món. L'efecte, quan més complexe es torna el cervell (mentres apren), més confiable es torna. Per contra, la confiabilitat del programari empitjora mentre la seva complexitat augmenta. Qualsevol aplicació de programari amb la complexitat del cervell estarien innundats d'errors que el farien inutilitzable. A la inversa, donada la seva relativa baixa complexitat, les aplicacions de programari amb la confiabilitat del cervell gairebé mai fallarien.
La confiabilitat del cervell és molt, molt més gran en ordre de magnitud a qualsevol programa existent. Tot just com pujar i baixar de cop escales sense gent i coses adins, o conduir al voltant de la ciutat (els taxistes ho fan tot el dia, cada dia) sense perdre's, o en un accident és increiblement més complexe que qualsevol programa existent pugui aconseguir. Imagina com de complexe és poder reconeixe la cara d'algú sota tot tipus de condicions d'il·luminació, de velocitats i orientacions? Ho fem a tota hora. Com de difícils són les tasques que una lleona ha de realitzar quan captura una pressa? O un col·libri que vola al voltant en búsqueda del nèctar? Els investigadors de ròbòtica es maravellen continuament de la sorprenent robustesa del comportament complexe exhibit per criatures tant primitives com les abelles i els escarbats. Segur que ens equivoquem, però les coses que fem són tan complexes, especialment les petites coses que oblidem, que els nostres errors empalideixen en comparació als nostres èxits.
El comportament dels sistemes nerviosos biològics són la prova que la confiabilitat d'un sistema (igual que un programa informàtic) no té que ser inversament proporcional a la seva complexitat. Però el cervell no és la única prova que tenim de l'existència de la solució definitiva. Tots coneixem la sorprenent confiabilitat dels circuits integrats. En tots els anys que he tingut i utilitzat ordinadors, només he tingut una fallada en la CPU i era perqué el ventilador va aturar-se. Ningú pot negar seriosament que una CPU moderna és un dispositiu molt complexe, que amb alguns dels xips d'Intel, d'AMD i d'altres dels centenars que estan formats per milions de transistors. La llei de Moore no sembla haver tingut efecte en la confiabilitat del maquinari doncs, com penso, la confiabilitat de les CPUs i d'altres circuits integrats de gran escala no es degraden durant els anys mentre augmenten de velocitat i de complexitat.
Apuntant la Complexitat Errònia
Aquests fets completament irrefutables i decisius refuten els arguments de "Cap Solució Definitiva" de Fred Brook per la que es relacionen la complexitat i la confiabilitat del comportament. Aquest no hauria de dir que les argumentacions de Brook són incorrectes però que no s'apliquen a la complexitat en general sinó solsament a una forma específica de complexitat, el del programari algorítmic. El Dr. Brook tenia un tipus particular de programari en ment quan va escriure el seu famós article, així que potser va tenir la impressió que tot el programari es creat de la mateixa forma. En la resta de l'article, discutiré que tot l'esforç en temps i diners que es destinen a programari més confiable s'està apuntant una complexitat incorrecta. I és particularment una forma de complexitat insidiosa i intractable, una forma que la humanitat, afortunadament, no hi ha de viure. Canviar a la complexitat correcta i el problema es soluciona.
La pregunta del milió (bilió?) de dolars, que fa que els sistemes nerviosos biològics i els circuits integrats siguin confiables a pesar de la seva complexitat? Però encara més importat, podem emul·lar-ho en el nostre programari? Si la resposta és si, llavors hem trovat "La Solució Definitiva".
La Solució Definitiva
Perqué el Programari És Dolent
La principal raó del programari dolent és que està basada en algoritmes, una pràctica tant vella com Lovelace i Babbage (*). Un algorisme no és diferent a una cadena. Trenca una de les anelles i la cadena sencera estarà trencada. Amb el programari algorítmic és virtualment imposible garantitzar la sincronització de varis processos perqué els temps d'execució dels subprogrames varien imprevisiblement. Varien principalment degut a una construcció anomenada "Ramificació Condicional", un mecanisme de desició utilitzat en seqüències d'instrucció. Però això no és tot. Mentres s'executa un subprograma, el programa que que el crida entra en coma. L'utilització de fils i l'enviament de missatges entre els procesos alleuja una mica el problema però la solució dels multi-procesos és massa feixuga i poc manejable en usos molt complexes. A més, un procés és exactament un altre algoritme. La incertessa temporal inherent (des del punt de vista del programador) dels sistemes algorítmics duen a programar les decisions en un moment equivocat, sota condicions errònies.
Els cervells i els circuits integrats són, en canvi, sistemes paral·lels basats en senyals. La seva confiabilitat es deguda sobre tot a dues raons:
- L'ajust estricte del senyal precís a través de la sincronització. Les neurones s'ensenen a l'hora adient, sota condicions temporals corretes. La sincronització és constant degut a l'arquitectura sincrona i paral·lela del cervell. Una equivalencia pot fer-se amb els circuits integrats.
- L'altament distrubuida naturalesa dels components elementals del cervell. Això significa que les fallades de funcionament d'alguns (o molts) components no causaran la fallada catastròfica del sistema sencer.
Els programes com sistemes de comunicació
Considera que relament un programa informàtic és un sistema de comunicació encara que no estiguem acostumats per pensar en ell com a tal. Durant l'execució, cada declaració en un codi esencialment procesal envia una senyal a la següent declaració, que significa: "He acabat, ara et toca a tu". Una declaració es pot considerar com un objecte elemental que té una sola entrada i una sola sortida. En un algoritme, les objectes s'enllacen junts per formar una cadena seqüencial. La comunicació es limita a només dos objectes a l'hora, a un emisor i un receptor. La meva tesi és que aquest mecanisme és massa rígid i restrictiu i fa que el programari no sigui fiable. Per qué? Perqué de vegades en una acció particular s'ha de comunicar a varis objectes a l'hora. Els entorns algorítmics de desenvolupament dificulten unir branques de senyals a un procés seqüencial i així enganyen el problema. La dificultat està en el programador al tenir que recordar-se d'afegir codi per gestionar casos de reacció endarrerida: quelcom que va ocorrer previament dins els procediment necessita tractar-se abans. Sovint ens oblidem d'afegir el codi necessari o oblidem de fixar la dependencia. El resultat és el que jo dic "Codi Ocult".
La cura pel Codi Ocult
La manipulació de dependències ha de fer-se de la forma correcta. De fet, molts parts d'un programa poden dependre críticament dels canvis d'una variables o característica. Amb freqüència succeeix que la variables es modifica per una declaració en un codi processal desconegut per la resta del programa. Quan les altres parts s'adonen de la modificació, el mal ja està fet. S'ha de conneixer molt a fons un programa complexe per recordar totes les dependències. Degut al gran volum de vendes en la industria del programari, els programadors hereden sovint codi extrany que agreuxa el problema. Encara que hi estiguis molt familiaritzat, això no és garantia d'un programari sense errors. Molt sovint un programa es tan gran i complexe que els seus autors originals perden totalment de vista dependències antigues.
El codi ocult duu a assumcions incorrectes que causen falles catastròfiques. Aquest és un problema que no existeix en un sistema paral·lel perqué cada canvi en una característica es di´fon inmediatament a tots els objectes a quí els hi afecta. Tots els objectes, d'alguna manera, han de tenir ulls al clatell. L'utilització dels detectors del canvi (sensors) solucionarà aquest problema vigilant els efectes secundaris en el seu comportament. De fet, el sistema de desenvolupament ha d'advertir automàticament de cualsevol pèrdua de dependència, no deixant res a l'atzar. Si es trova una dependència, l'emisor ha de tindre l'opció de deixar que el sistema corregeixi el problema automàticament. Afortunadament, aquestes són el tipus de coses que es poden possar facilment en exexució en un entorn de desenvolupament conduit per senyals: només afegint una ruta de senyal (mireu el sistema operatiu COSA).
Components Compatibles en Connexió
Molta gent ha suggerit que els programes informàtics es componentitzi (muntar-se a base de components) amb l'esperança de fer pel programari el que van fer els circuits integrats pel maquinari. De fet, la componentització és un pas gegant en la direcció correcta. Però, encara que l'ús dels components de programari (p.e, els controls ActiveX(r) de Microsoft, els Beans de Java, els objectes de C++, etc...) en l'última dècada a automatizat molt la dificultat de la programació, el problema de la confiabilitat encara existeix. La raó és obvia: els components de programari es construeixen amb elements completament aliens a un dissenyador de circuits integrats del maquinari: algoritmes. Un component algorítmic probat a fons pot treballar molt bé en un ús i fallar en un altre. La raó és que el seu comportament temporal no és constant. Varia a causa de l'entorn de l'altre. Aquest problema no existeix en un model paral·lel que fa que sigui ideal com a plataforma pels components.
Els objectes síncrons van més enllà per solucionar molts dels problemes més repugnants del programari. Un altre motiu conegut del mal programari té a veure amb la compatibilitat. Dins el cervell, els camins de la senyal no estan connectats "willy-nilly". Les connexions es fan segons els seus tipus. Fixeu-vos, per exemple, una empremta retinal: les senyals d'una cèl·lula retiniana del gangli arriben a una neurona específica de cortex visual que van fins a la part posterior del cervell. Això s'aconsegueix via un mecanisme bioquímic d'identificació durant el deselvolupament inicial del cervell. És una forma de de fer compatible les parts connectades del cervell.
Hauriem de seguir l'exemple de la natura i utilitzar un sistema estricte per definir el nostre programari per assegurar la compativilitat entre els objectes al comunicar-se. Tots els connectors del missatge han de tenir tipus de missatge, i tots els connectors han de ser unidireccionals, es a dir, han de ser mascle (emisor) o femella (receptor). Això eliminarà l'augment de variacions i assegurarà una connectivitat robusta. Els components compatibles en la connexió han d'encaixar-se automàticament junts a pressió: amb un clic o un mou i deixa. La dificultat d'assegurar la compatibilitat no ha de basar-se sobre el programador sinó sobre el sistema de desenvolupament.
L'utilització de les biblioteques comprensives de components pre-contruits automatitzarà un 90% del procés de desenvolupament del programari i transformarà els usuaris en creadors de programari. Alguns poden dir que els connectors del missatge no són res de nou i són correctes. Els objectes que es comuniquen via els connectors s'han intentar fer abans amb molt bons resultats. Tanmateix, com ja he dit, en un sistema pur basat en senyals, objectes que no tinguin algoritmes. Enviar una senyal definida a un objecte síncron no és el mateix que invocar un procediment a un objecte de C++- L'únic codi algorítmic pur que ha d'existir en tot el sistema es un petit microkernel del Sistema Operatiu. Cap codi executable nou pot permetres de la forma que funciona el microkernel. A més, el paral·lelisme subjacent i el mecanisme de senyals han d'executar-se en el sistema operatiu de tal manera que sigui completament transparent al dissenyador del programari. (una mica més aprop del sistema operatiu COSA).
Ordenar Events És Crític
La sincronització consistent és vital per la confiabilitat, però com he explicat anteriorment, l'ús d'algoritmes juga un paper important a l'hora d'ordenar events. Per asegurar la consistència temporal de l'ordre, l'ordre preescrita de cada operació o l'acció de l'ús d'un programari s'ha de mantindre al llarg de la vida de funcionament, sense importar l'entorn de l'amfitrió. No es pot permetre que passi abans o després del moment adient. En un entorn de desenvolupament basat en senyals, l'aplicació de l'ordre no es quelcom que els emisors necessiten tenir en compte perqué és una conseqüència natural del paral·lelisme del sistema. El resultat final es que la confiabilitat d'un sistema sincron i paral·lel és proporcional a la seva complexitat. Això és aixó perqué s'afegeixen noves rutes de senyals i les connexions també afegeixen noves restriccions temporals al sistema, fent-ho més robust.
Fixa't que el terme "sincronització consistent", utilitzant abans, no significa que les operacions han de sincronitzar-se en un rellotge de temps real. Significa que l'ordre lògic o relatiu preescrit de les operacions s'ha de fer complir durant la vida del sistema i mantenir-se en diferents plataformes.
Pensant en Tot
Jeff Voas, co-fundador de Cigital, una firma consultora de la confiabilitat del programari a Dulles, VA, un cop va dir que "és de les coses que mai pensarás que s'aconsegueixin sempre". És cert que un no pot pensar en tot, especialment al treballar en sistemes algorítmics. Tanmateix, també és veritat que un sistema es pot idear de tal manera que totes les dependències i incompatibilitats internes siguin vistes automàticament, alliberant al programador de pensar en tots ells. El comportament temporal consistent i l'ús de detectors del canvi i dels components compatibles en connexió, tal com s'ha descrit abans, aconseguirant l'eliminació de la majoria d'imprevistos.
Imitar el Paral·lelisme de la Natura
Per solucionar la crisi hem d'imitar la natura. Els objectes a la natura es comporten sincronament. Per qué han de ser diferents els objectes del programari? Hem de parar d'utilitzar l'algoritme com a base de la programació informàtica. Hem de parar, d'un cop, de pensar en l'ordinador com una màquina per la execució de seqüències d'instruccions. L'ordinador ha de veure's com un sistema de comunicació, és a dir, una col·lecció d'objectes síncrons que interactuen recíprocament. És a dir, el programari ha de ser més com el maquinari amb els diferents objectes i mòduls que interactuen recíprocament que treballen en paral·lel, enviant i revent les senyals dels altres mitjançant les seves connexions d'entrada i sortida.
L'Arquitectura Von Neumann
Alguns poden dir que el programari és intrinsecament secuencial degut a l'arquitectura Von Neumann dels nostres ordinadors. Això és veritat, però gràcies a la velocitat dels processadors moders, podem simular fàcilment el paral·lelisme dels circuits integrats o del sistema nervios en el programari. Això no és nou. Ja simulem el paral·lelisme de la natura en les nostres xarxes neurals artificials, autòmates cel·lulars, video jocs i altres tipus d'ús de la simulació.
Un, pot anar més enllà i dir que els algoritmes segueixen essent uniformes encara que no siguin visibles a l'emisor i que, per tant, la falta de fiabilitat del programari algorítmic no pot evitar-se. Això seria cert si la falta de fiabilitat era a causa de l'ús d'un sol algoritme o a un grapat d'ells. Això no és el que s'observa ni el que està descrivint aquest article. És realment possible crear un procediment algorítmic sense defectes. Ho fem a tota hora. La falta de fiabilitat bé de la proliferació desenfrenada de procediments i de la complexitat i de la imprevisió de les seves interaccions. Tanmateix, en un sistema de programari síncron, no es permet cap més nou codi algorítmic.L'únic algoritme de tot el sistema és un petit nucli, altament optimitzat i provat a fons la seva execució que és responsable de simular el paral·lelisme del sistema. La ferma prohibició contra l'afegit de nous codi algorítmic garantitza amb eficàcia que el sistema seguirà essent estable.
Per altra banda, la meva esperança és que els principals fabricants de circuits integrats (Intel, AMD, Motorola, etc...) aviat reconeixeran la importància dels objectes síncrons del programari i fabricaran CPUs amb un disseny molt optimitzat específicament per a aquest tipus de paral·lelisme. D'aquesta manera, el tot el nucli de la execució es podria fer per que estigués dins el xip de la CPU. Això donaria lloc a un funcionament robust i sense paral·lelisme. Per saber-ne més, mireu el cucli del Sistema Operatiu COSA.
Circuit Integrats de Programari amb un Canvi
En un article del 1995 titulat "Que? si hi ha una Solució Definitiva...". El Dr. Brad Cox (dissenyador del llenguatge de programació Objective-C) va escriure el següent:
La construcció d'aplicacions (mòduls de nivell de rac) amb tecnologies altament relacionades com les llibreries dels subprogrames (mòduls de nivell de bloc) lògicament, només és equivalent a la integració a l'escala d'oblies, quelcom que la ingenyeria del maquinari pot aconseguir fàcilment avui en dia. Només fa set anys, Steptone va començar a realitzar un paper semblant al dels venedors de xips de silici, proporcionant components de programari de nivell de xip, o Programari-CIs[c], a la comunitat de la construcció de sistemes.
Mentres que estic d'acord amb l'ús dels mòduls per la composició del programari, modifico l'analogia del Dr. Cox sobre tot perqué les llibreries de subprograma no tenen cap anàlog en el disseny de circuits integrats. La diferència més grant entre el maquinari i el programari convencional és que l'anterior funciona en un univers basat en senyals i paralel on la sincronització és sistemàtica i constant, mentre que els algoritmes seqüencials de les últimes aplicacions donen lloc a la sincronització casual. Aquesta és el principal motiu pel qual el maquinari és molt més confiable que el programari.
El programari no ha de ser radicalment diferents al maquinari. Quelcom, ha de servir per extendre'l. El programari ha d'emular la funcionalitat del maquinari afegint només el que li fa falta: flexibilitat i facilitat per la modificació. En el futur, quan desenvolupem les tecnologies per les noves màquines no-Von Neuman que poden sorgir noves formes de senyals físiques i nous objectes auto-executables a l'instant, la diferència entre el programari i el maquinari no existirà més.
Un altre motiu que els circuits elctrònics lògics són més confiables que el programari és aquells que els problemes es mesuren en el temps que pesiguen al sorgir degut al paral·lelisme inherent del maquinari. Els circuits no funcionaran correctament si la sincronització és incorrecta. Però un cop la sincronització trobi el punt on els circuits funcionen fluidament, continuaran així per tota la vida del sistema, excepte algun error físic. Per tant, l'aplicació de la temporització automàtica, el paral·lelisme del sistema i el sincronisme són algunes de les claus de la confiabilitat.
Localització dels Errors
Un programa algorítmic és com una cadena, i una cadena és tant forta com el seu acoblament més dèbil. Trenca qualsevol acoblament i la cadena sencera estarà trencada. Aquesta fragilitat es pot reduir amb l'ús de múltiples processos paral·lels. Un procés que funciona malament no afecta normalemnt al funcionament correcte dels altres processos. La localització de l'error ñes una forma molt eficaç d'augmentar la tolerància a averies del sistema. Per la trista realitat és que, encara que els sistemes operatius multiprocessos són la norma en la indústria del programari, els nostres sistemes segueixen sent subceptibles a errors catastròfics. Per qué? La resposta és que els processos no eliminen completament la codificació algorítmica. Encapsulen algoritmes en els programes concurrents que funcionen en el mateix ordinador. Un altre problema encara més seriós amb els processos és que són, per necessitat, asincrons. La comunicació síncrona entre els objectes que interactuen recíprocament és necessari per la confiabilitat.
Els processos poden dur un alt preu degut al funcionament de sobre asociat al canvi de contexte. Augmentant el nombre de processos així en un sistema que encapsuli i fagi paral·lelisme de les operacions elemetals ràpidament és irrealitzable. Les conseqüències del funcionament serien enormes. Afortunadament, hi ha una tècnica simple de paral·lelisme que eliminar els processos en conjunt. S'utilitza normalment en altres úsos com els autòmates cel·lulars, les xarxes neuronals, els simuladors i altres programes. Mireu el projecte COSA per més detalls.
Augmentant la Productivitat
Com pot, l'adopció d'un paradigma del programari pur basat en senyals i el sincronisme augmenten la productivitat? La resposta té que veure amb les senyals i com es relacionen els components del programari. Un model concurrent i síncron s'acomoda bé en un entorn gràfic pur de desenvolupament per la composició del programari. Hem d'abandonar el nostre passat lingüístic i textual i adoptar un futur visual. Per ningú hi ha d'haver un llenguatge secrect que aprendre. En segon lloc, es molt més fàcil seguir camis d'activació de senyals en un diagrama que desxifrar a algú els múltiples camins extesos pel codi algorítmic obscur del texte. El dissenyador de l'ús pot aconseguir molt millor una sensació pel fluxe de les coses mentre cada senyal es propaga a partir d'un objecte a altres utilitzant camins unidireccinoals.
Els arguments anteriors són deguts principalment a un augment en la claretat. Però el que realment elevarà la productivitat en un ordre de magnitut alt serà el mins nombre d'errors a trobar. En coneixement comu en que el temps de desenvolupament del programador mitjà està sobretot basat en la prova el l'eliminació d'errors. Per suposat, l'ús de les conexions de components (sel·lecció i moure i deixar) evitarà i eliminarà tots els tipus de problemes asociats a un codi incompatible automatitzant una gran part del procés de desenvolupament. A més, els entorns de desenvolupament tindrán les eines de possada a punt que trobaran, corregiran i previndran automàticament la majoria dels errors ocults. En resum, un entorn síncron, basat en senyals facilitarà el desenvolupament segur, l'automatització del programari i obrirà la programació informàtica al públic laic.
Conclusió
Matem al Llop d'una Vegada per Totes
Com a conclusió, podem solucionar la crisi de la confiabilitat i de la productivitat del programari. Per fer-ho, hem de reconeixer que hi ha quelcom putrefacte en la base de la tecnologia de dotació lògica. Hem d'entendre això que utilitza l'algoritme, doncs la base de la programació informàtica és la causa principal del problema. L'apropament algorítmic és l'últim dels impediments que impedeixen que aconseguim una componentització eficaç i segura del programari comparable al que s'ha fet en el maquinari. És el motiu que les mesures actuals de control de qualitat fallaran sempre a l'extrem. Adoptar un model síncron del programari s'assegurarà de que els nostres sistemes aconsegueixin ser més robustos i tant confiables per a que creixin més grans i més complexes.
La confiabilitat del programari és crítica per la seguretat del món. Ha arribat massa a formar part de la nostra vida diaria que es confiarà a un paradigma anticuat i fet malbé. Necessitem un nou apropament digne al segle vint-i-ú i ho necessitem desesperadament. No podem permetre'ns simplements continuar fent negoci com de costum. Frederick Brooks té raó sobre una cosa. No existeix la Solució Definitiva que pugui solucionar el problema de la confiabilitat dels sistemes algorítmics. Però, com he explicat, Brooks i altres fallen al considerar que els seus arguments s'apliquen solament al programari algorítmic. La "Bala" s'ha d'utilitzar per matar la béstia d'una vegada per totes, no per alleujar els síntomes de la seva enfermetat incurable.
Continuarà....
