Newsgroup: it.lavoro.informatica
Titolo: java lo considerate ancora un linguaggio moderno?

oggi voglio fare una mezza trollata alla anoquick.



pensate ad una applicazione jee dentro ad un container: ha ancora senso 

la java virtual machine? 

non mi riferisco solo ai problemi, ormai per fortuna obsoleti, dovuti al 

fatto che il runtime non onora(va) i limits dei cgroups (bel pacco, eh). 

parlo in generale dell'utilità di avere una jvm dentro un container con 

tutti gli orpelli che si porta dietro, in massima parte inutili. 



personalmente è da quando si è cominciato ad usare pesantemente i 

container che ho una posizione critica. 






Il 20/05/20 11:05, rootkit ha scritto:


l'hai fatto apposta di la verità volevi provocarmi



JAVA FA CAGARE un linguaggio nato per le lavatrici e i frigoriferi.



strati, su strati, su strati per dargli un senso a livello gestionale.



UN CAGATA PAZZESCA , che ancora oggi mi domando come cazzo ha fatto 

l'ibm ad apprivare una tecnologia di merda come java.



piu critico di cosi si muore.



-- 

grigio



Prova con il Maalox. Per via rettale; ça va sans dire.



-- 

The three most dangerous things in the world are a programmer with a 

soldering iron, a hardware type with a program patch and a user with an 

idea.



“Alles hat ein Ende, nur die Wurst hat zwei”


 



java è stato pensato per far programmare anche le donne e le teste di 

cazzo......dopo 10 anni hanno capito che è questione di testa e non di 

linguaggio.



ROTFL! infilatelo te il suppostone che fa rima con ....



-- 

grigio


 java è stato pensato per far programmare anche le donne 



COBOL, PORCODDIO, L'HA INVENTATO UNA DONNA. PORCODDIOOOOOOOOO cit.



game. set. match. cit.



Anche il capo progetto del linguaggio RPG è una donna.



 Anche il capo progetto del linguaggio RPG è una donna. 



uno schifo, signora mia. dove andremo a finire mah



;o) Chissà poi che gli avranno fatto le donne?....Poco, penso.



 COBOL, PORCODDIO, L'HA INVENTATO UNA DONNA> 



Ecco perché è così prolisso!





lol


 tutti gli orpelli che si porta dietro, in massima parte inutili. 

Potresti essere più preciso?

Credo che considerazione analoghe valgono anche per in RunTime di .NET o sbaglio?



Ciao

  Francesco


 uno schifo, signora mia. dove andremo a finire mah



davvero? non sapevo

però non lo "inventò" di sana pianta: 

imitava il ciclo delle tabulatrici UR,

forse la macchina di Turing

(forse perchè non so se Turing aveva previsto 

le "rotture di controllo" etc...)



a meno che non si tratti dello RPGIII, 

certamente chiacchierone




 forse la macchina di Turing 



che era gay.


 oggi voglio fare una mezza trollata alla anoquick.

e' enoquick, te lo passo come errore di digitazione.



per il resto non so di cosa parli.

Per me un qualsiasi linguaggio continua ad essere tre istruzioni.

Se qualcuno ne ha messe insieme un miliardo per far si che ti sbrighi

a fare l'uovo quello e' altro  problema.



-- 

ac (y-1=x)



-- 

Questa e-mail è stata controllata per individuare virus con Avast antivirus.

https://www.avast.com/antivirus






Quindi?

Meglio degli italiani?



On 20/05/2020 15:28, 
mar...@aureli.us
 wrote:


Prolisso un cazzo!

Allora ha ragione Musk a chgiamare su figli /sarcazzo/

azzerami una struttura in cui ogni elemento e' fatto da vari tipi di 

dati. Gestisci la stessa struttura decidendo /tu/ che cazzo di tipo dato 

siano!



 Meglio degli italiani?



guarda che "gay" non è una nazionalità.




 per il resto non so di cosa parli.



quando senti qualcuno e non sai di cosa parla ci tieni sempre a farglielo 

sapere?


 davvero? non sapevo



Figurati se lo sapevi.


 tutti gli orpelli che si porta dietro, in massima parte inutili.



Non considero Java un linguaggio moderno perche` hai ormai un quarto di 

secolo sul groppone e, con le versioni dopo la 8, stentano davvero ad 

innovarlo. Sviluppando, al momento, sia in Java che in 

JavaScript/TypeScript, apprezzo molto certe cose che posso fare nei 

secondi ma non nel primo. Pero` ritengo Java, ma soprattutto l'intero 

ecosistema attorno (vedi Spring Boot), ancora uno strumento molto valido 

per mettere in piedi certi sistemi basati su microservizi 

containerizzati. Non vedo un'alternativa facile al non usare una JVM a 

quel modo. Tu che idea alternativa hai in mente?


 ;o) Chissà poi che gli avranno fatto le donne?



pernacchie, incessanti pernacchie.


 Meglio degli italiani? 



quelli sono gaio, gai e gaie.


 sapere? 



è gaio cit.


 sapere?



LOL... e` tornato? E` nel kill file da una vita per cui non lo leggo. Ma 

ci pensi che una vita fa potevi ritrovarti colleghi come quelli? :D


 davvero? non sapevo



Si chiama Barbara Morris



 Per me un qualsiasi linguaggio continua ad essere tre istruzioni.



queste: "alessandro cara coglione"


 sbaglio?



questo non lo so perché non sono esperto del .net. quello che vedo ormai 

da diverso tempo è che i programmi java hanno un footprint inadeguato a 

realizzare microservizi, sebbene ci siano apprezzabili tentativi di 

ridurlo (vedi quarkus). e comunque trovo assurdo, oltre che inutile 

complessità, il fatto che ci sia da tunare questo aspetto nei container 

dove l'applicativo ha uno spazio tutto suo.


 realizzare microservizi,



E` vero, sopratutto in termini di memory footprint. Spring Boot e` 

effettivamente un bel mostro, in termini di consumi, ma al momento non 

vedo alternative. Quarkus e` molto interessante. Sicuramente qualcosa da 

valutare come alternative long-term. L'idea di migrare cosi` tante 

applicazione scritte con Spring Boot, pero`, mi fa venire i brividi.


 quel modo. Tu che idea alternativa hai in mente?



sto guardando con interesse linguaggi compilati come rust. il linguaggio 

è elegante, multiparadigma, coinciso quanto basta, tutto risolto a 

compile-time quindi niente sorprese a runtime, memoria gestita ma niente 

garbage collector. 

chiaro che di migrare non se ne parla nemmeno e comunque in azienda 

abbiamo una knowledge consolidata di java difficile da muovere. però mi 

pongo il problema. 


 pongo il problema.



Si`, sicuramente il problema esiste. A me ha fatto un po' scalpore la 

lista delle novita` in Java 14. Non mi sembrano affatto innovazioni. 

Sembra che anche il linguaggio stenti ad evolversi. Io switcho 

continuamente tra TypeScript/JS a Java e a volte mi rendo conto della 

prolissita` del secondo a confronto. Il panorama di linguaggi, comunque, 

e` sconfinato. L'idea di quanta roba c'e` da sapere e quanto poco tempo 

si ha per studiare e` deprimente. Io sto facendo 5-6 corsi in parallelo 

sulla piattaforma di e-learning O'Reilly. Nella mia lista, oltre al 

vecchio Python da rispolverare (che ormai e` vetusto pure lui), ho 

Kotlin, OCaml, Go. Ho dei colleghi patiti di Rust. C'e` veramente tanta 

carne da mettere sul fuoco.




 Si chiama Barbara Morris



è una giovinastra in IBM dal 1989

bruttina come lo RPGIII :-)



Sei il solito imbecille.



 Credo che considerazione analoghe valgono anche per in RunTime di .NET o sbaglio?



Dal basso della mia esperienza, temo di no.

Per carità, han fatto una roba abbastanza completa e abbastanza veloce, soprattutto nella versione .Core, però rimango sempre stupito dal peso di tutta la roba che si tira dietro un compilato in .Net.



-- 

Ciao!

Luca


 garbage collector. 



Curiosità mia: non trovi questo un difetto?



-- 

Ciao!

Luca


 bruttina come lo RPGIII :-)



Non che da te ci si aspettasse un commento che non fosse becero. 

D'altronde, argomenti tecnici non ne hai.


rimango sempre stupito dal peso di tutta la roba che si tira dietro un compilato in .Net.



Quindi la risposta e` si`, non no. No?




 sto guardando con interesse linguaggi compilati come rust.



PS appena sottoposta la questione ad un collega che mi ha risposto:



"Rust for everything

I’m even writing my UIs in it now with WebAssembly"



:)


 Sei il solito imbecille.



https://www.linkedin.com/in/barbara-morris-36051610/?originalSubdomain=ca


ti pare carina?


 ti pare carina?



Ma chi cazzo se ne fotte se e` carina. Hai 80 anni e ragioni come un 

quindicenne?




 D'altronde, argomenti tecnici non ne hai.



si stava parlando di che ha inventato lo RPG, la Morris nò di certo



se vuoi uno che ha molto spaziato

http://www.retrocomputing.net/info/siti/windoweb/www.windoweb.it/edpstory_new/el_rpg.htm





 Quindi la risposta e` si`, non no. No?



Domanda: "Credo che considerazione analoghe valgono anche per in RunTime di .NET o sbaglio?"



Risposta: "Dal basso della mia esperienza, temo di no."



Nel senso, ovviamente, "non sbagli".



-- 

Ciao!

Luca


 ti pare carina?



Sono curioso. Esattamente questo come dovrebbe contare nella valutazione della sua capacità e competenza?


 si stava parlando di che ha inventato lo RPG, la Morris nò di certo



E` stato scritto questo: "il capo progetto del linguaggio RPG" e la 

biografia di Barbara Morris riporta: "Barbara Morris is the lead 

developer for the RPG compilers in the IBM Toronto Lab. She has been 

working on the RPG compilers since she started at IBM in 1989"

https://powerup18.sched.com/speaker/barbara_morris.1tko7m4t




Come, poi, queste informazioni si tramutino nella tua testa, non 

interessa a nessuno.



Devi ancora spiegare come il fatto che sia "carina" abbia o meno a che 

fare con le capacita` di questa persona. Vergognati. Quando non hai 

argomenti, astieniti.








 Nel senso, ovviamente, "non sbagli".



Sei veramente un comunicatore.



Tu invece sei proprio imbecille.




Ho detto che è, da molti anni, responsabile tecnica del progetto. Imbecille!



 
http://www.retrocomputing.net/info/siti/windoweb/www.windoweb.it/edpstory_new/el_rpg.htm


non pare certo pensarla come me



salutami il tempestatore degli imbecilli





no, perché ha ovviamente un meccanismo alternativo oggi come oggi più 

efficiente. 



https://medium.com/@thomascountz/ownership-in-rust-part-1-112036b1126b



 efficiente. 



Interessante l'articolo, anche se a me manca qualcosa.

I grossi casini, in C, erano riconducibili a due cause: una chiamata a malloc senza fare la free conseguente e una gestione di allocazione/deallocazione scriteriata che avrebbe portato alla frammentazione della memoria (*). Ora, se capisco bene, si dice: non sei tu che gestisci lo heap: è il compilatore che predispone in modo che dello heap si arrangia lui, sia per allocazione che deallocazione (all'uscita dallo scope), e ti viene tirata via qualsiasi altra possibile sorgente di casino grazie al modello di ownership.

Mi manca (leggi, c'è di sicuro ma non mi par di avelo visto nella coppia di articoli che mi hai linkato): OK, ha senso, se lavori con lo scope e con l'ownership previeni i casini del primo tipo; ma come previeni la frammentazione se non hai qualcuno che gestisca il tutto intervenendo se del caso a risolvere i casini? Bah, adesso mi hai messo la curiosità, vado a cercare qualche info in più.



(*) Il garbage collector è servito principalmente per gestire questo aspetto



-- 

Ciao!

Luca




 bruttina è bruttina



Non frega un cazzo a nessuno.


ma come previeni la frammentazione 



La frammentazione la gestisce il sistema operativo. Le chiamate a 

malloc/free sono mappate su chiamate di sistema.


 bruttina è bruttina



Mi sono preso la libertà di guardare la tua foto su FB.

Minchia, hai il coraggio di definire bruttina una persona e dirlo con 

quella faccia? Popò di stronzo, diocane.



 quella faccia? 



E non solo con la sua...




 Era una domanda retorica.



se non volete risposte da me o se non v'interessa ciò che scrivo,

perchè ribattete?





io non riesco a capire l'italiano che segue,

già me lo hai spiegato, ma l'ho perso: mi daresti il link?

oppure me lo torneresti a *tradurre* ad uso della mia stupidità? 

------------------------------------------------------------------

“Non è vero ma ci credo” di John Brockman (ilSaggiatore) pag. 124 

Charles Simonyi, “scienziato” informatico della Microsoft scrive: “… ci 

siamo impantanati … i computer sono migliorati diecimila volte … eppure … 

per tradurre in un programma per computer un problema amministrativo, 

che si potrebbe descrivere dettagliatamente in cento pagine, … ci vogliono

milioni di dollari e spesso il programma non funziona …”  

....

“… poi bisogna dare ai programmatori la possibilità di scrivere non un programma per risolvere il problema in sé, ma un generatore di programmi, che combinerà i contributi degli esperti sulla materia ai dettagli per l’implementazione …”.

------------------------------------------------------------------

grazie








 io non riesco a capire l'italiano che segue,



Tu non capisci un bel po' di cose. Non ti affannare a scrivere roba. Non 

appena intravedo le tue solite minchiate, io taglio i messaggi di netto.


 appena intravedo le tue solite minchiate, io taglio i messaggi di netto.



verissimo

hai tagliato la storia di Simonyi che scriverebbe una roba  

diversa da quel che si legge;

l'altro giorno hai detto d'avermelo spiegato: 

dove?






 hai tagliato la storia di Simonyi



Ancora co' 'sto Simonyi? A che serve spiegarti roba che non comprendi 

perche` non sei in grado di comprendere?



Selmi, tu devi avere seri disturbi mentali per essere cosi` ossessionato 

dalle stesse 3 cazzate da 40 anni. Fatti curare.




 dalle stesse 3 cazzate da 40 anni. Fatti curare.



sei di già rimbambito? 

pensa a qiando avrai la mia età!

Simonyi ha scritto quella roba nel 2010 o giù di lì,

e tu non sei capace di tradurre in italiano

"... ci vogliono milioni di dollari e spesso il programma non funziona ...”  

?

sù che è facile!

è di già in italiano






 interessa a nessuno.



Mi permetto di dissentire, antropologi e psichiatri farebbero a gara per 

accaparrarsi il cervello "AB NORMAL" di selmi, se non altro, per 

verificare come il suo canale spinale termini nel buco del culo.

:-)


 verificare come il suo canale spinale termini nel buco del culo.



ti scoccia si sappia che nonostante la tua alta presenza 

il JD che mi sostituì fu capace sopratutto di aumentare enormemente i costi?

non c'è nulla di male: tu agivi nell'interesse tuo e dei tuoi compari,

io nell'interesse della mia ditta, credendo a torto foss'anche il mio



ma è acqua passata



tu non dovresti essere di già rimbambito

aiuta il tuo amico andrea

tu sei certo capace di tradurre Simonyi in italiano:

"... ci vogliono milioni di dollari e spesso il programma non funziona ...”  



 il JD che mi sostituì fu capace sopratutto di aumentare enormemente i costi?



Sono assolutamente indifferente, per quanto ne sappia la scelta fu 

dell'azienda, io non ne fui minimamente coinvolto ne' ho fatto alcuna 

analisi dei costi sia preventiva che consuntiva, quindi si tratta 

meramente di una tua opinione, impossibile da verificare ora tantomeno qui.


 sei di già rimbambito?



Ma vattela a prendere nel culo.


 meramente di una tua opinione



Evidenza aneddotica, come sempre. Ma ti rendi conto che 'sto tizio ha 

lavorato meno di 30 anni (e prende per il culo la Morris!) ed e` 

ossessionato da un trentennio da tre cose: JD, Simonyi, e-voting.

E qualsiasi argomento di informatica gli sottoponi, ti risponde con un 

"non so di cosa stai parlando".

Allucinante.




 Mi permetto di dissentire, antropologi e psichiatri farebbero a gara



Verissimo. Non avevo pensato all'interesse clinico. Immagino gia` gli 

esperimenti: il suo cervello da un lato, un culo dall'altro, e la 

scoperta che certe cose entrano meglio nel secondo che nel primo.





Gia'. L'evidenza empirica, quello dice: le cose che entrano nel secondo 

arrivano nel primo trasformate in merda durante il tragitto.


 meramente di una tua opinione, impossibile da verificare ora tantomeno qui.



poichè qui non si usano documenti bollati

potresti chiedere a Vero Greco se non è *vero* quello che io ho riferito :-)

oppure startene zitto

oppure evitare di sbellicarti assieme ai tuoi scagnozzi quando scopristi

che io ero quello che si faceva (a tuo dire) prendere per il culo da

Ortensi, il direttore di News 3X/400



in ogni caso visto che a tuo parere e di altri io sarei persino incapace

di intendere l'italiano, perchè non mi traduci in dialetto locale

------------------------------------------------------------------

“Non è vero ma ci credo” di John Brockman (ilSaggiatore) pag. 124

Charles Simonyi, “scienziato” informatico della Microsoft scrive: “… ci

siamo impantanati … i computer sono migliorati diecimila volte … eppure …

per tradurre in un programma per computer un problema amministrativo,

che si potrebbe descrivere dettagliatamente in cento pagine, … ci vogliono

milioni di dollari e spesso il programma non funziona …”  

....

“… poi bisogna dare ai programmatori la possibilità di scrivere non un 

programma per risolvere il problema in sé, ma un generatore di programmi, 

che combinerà i contributi degli esperti sulla materia ai dettagli per 

l’implementazione …”.

------------------------------------------------------------------

?

questa è roba del 2010 circa

possibilissimo che ora i problemi del 2010 circa siano stati risolti

come hanno fatto?

così come diceva Simonyi?



sarei poi curioso di sapere che robe doveva fare quella contabilità

spero non quintali di merda




 Ortensi, il direttore di News 3X/400



I commenti su news3x sono ancora li', nero su bianco, ma visto che "qui 

non si usano documenti bollati", allora "startene zitto" vale anche per te.

Quello che ho percepito allora, e' che la scelta di JD fu fatta senza il 

tuo apporto, visto che finche' hai potuto hai remato contro qualsiasi 

cosa. Tutto cio' senza carta bollata, quindi stattene zitto.








 come hanno fatto?



Vuoi che ti spieghiamo le metodologie agili in 3 righe? E a che pro, dal 

momento che non capiresti? (Bada che anche questo ti era stato gia` 

detto, stupidotto!)


 cosa.



:'''D




 Tutto cio' senza carta bollata, quindi stattene zitto.



guarda che io mi consideravo un informatico perfettamente in grado di fare meglio dei pacchettari visto che era desiderato un pacchetto su misura

e visto che io conoscevo benissimo la situazione (e in più avevo già

roba pronta); io remavo pro-azienda e i fatti mi giedero ragione: 

diversi anni per installare JD e costi alle stelle, sulla *qualità* finora 

mi hai parlato tu solo, ma non doveva essere eccelsa se dopo pochi anni 

sono passati a Oracle (Greco aveva venduto la ditta, ma mi disse che neanche 

con Oracle le cose migliorarono) e guarda che JD si confrontava con roba 

fatta nel periodo 75-95, mediamente stile anni 85 (escluso l'officina visto 

che copiarono la mia)



questo te l'ho detto più volte e, altri impegni permettendo, te lo ripeterò 

con piacere fino a quando non te ne starai zitto TU














 guarda che io mi consideravo un informatico



Era questo il tuo errore. Non lo sei mai stato.




 la java virtual machine? 



no hai ragione. ma la jvm è java.



potremmo prendere java di eoni fa, con le sue jvm meno ricche e meno invasive? retorica.



un'idea altrove, è quella di tagliare i layers dove si può creando un sistema di programmazione più autocontenuto vedi ad es. MirageOS.




 mi ripeto: se dubiti delle mie parole perchè non lo contatti?



visto che "qui non si usano documenti bollati", allora "startene zitto" 

(parole tue) vale anche per te.


 detto, stupidotto!)



hai ragione bastava guardassi qua

https://it.wikipedia.org/wiki/Metodologia_agile


devo proprio ringraziarti

----------------------------------------

... metodologia agile (o sviluppo agile del software... e emersi a partire dai primi anni 2000 e fondati su un insieme di principi comuni... I metodi agili si contrappongono al modello a cascata (waterfall model) e altri modelli di sviluppo tradizionali, ... obiettivo di consegnare al cliente, in tempi brevi e frequentemente ... software funzionante e di qualità.

... formazione di team di sviluppo piccoli ... sviluppo iterativo ...  e il coinvolgimento diretto e continuo del cliente nel processo di sviluppo. 

......

... metodologie di sviluppo leggere e flessibili, che rompono con la precedente tradizione di ingegneria del software (modello a cascata, modello a spirale, etc.)...

---------------------------------------------------------------

anch'io dubitavo che l'INGEGNERIA DEL SOFTWARE fosse la soluzione giusta,

sull'argomento scrissi a un giornale e questa fu la gradita conseguenza

https://digilander.libero.it/gino333/ericson.jpg




la differenza (metodologica, sui risultati occorrerebbe un confronto 

pratico reso difficile dal tempo intercorso) fra me e gli *agili* sta 

nel fatto che io ho cominciato come capocentro-analista-programmatore 

e sono rimasto tale fino alla fine, inoltre ho avuto la fortuna di poter

crescere gradualmente con lo sviluppo dell'informatica: ho avuto tempo 

per imparare, soprattutto ho quasi sempre avuto terreno vergine (solo

nell'ultimo impiego ho ereditato un po' di casini  da una precedente

meccanizzazione poi peggiorata dalla conpresenza dell'ORGA )



Oggi invece i compiti sono certamente più specializzati, impossibile

avere una visione globale d'azienda (o altra organizzazione)e soprattutto

già molto è stato informatizzato quindi è probabile che di debbano fare

della *aggiunte* a qualcosa di preesistente che certamente vincola

terribilmente.



Io ho avuto la fortuna di poter fare a meno dei ragioniericulodipietra,

non perchè non ci fossero, non che l'ok finale non spettasse a costoro,

(unitamente al padrone ovviamente), ma io (salvo un caso particolare,

quello della Tesoreria, dove campanandoci poco mi fidai del tesoriere, 

persona molto in gamba) io, dicevo, conoscevo abbastanza bene le questioni 

(o m'informavo adeguatamente) perciò la mia metodologia era *agile*



Tuttavia non avevo bisogno di "team di sviluppo", bastavo io assiema a 

una iterazione continua con me stesso e con gli utenti (strada facendo è 

facile dover cambiare idea)



ora è noto che far da se fa per tre

se poi fai da te anche quello che normalmente farebbe  un "team aziendale"

hai un altro per tre; 

poi 3x3=9 ... :-)



Se Simonyi ha risolto dopo il 2010 i suoi problemi con l'agilità (nata nel 

2000) devo dire che ci ha messo un bel po' a capire l'antifona, peggio di

quelli che brontolavano sull'AS :-)



Chissà dov'è finito quel D'Ascenzo.

Chissà se ha saputo che eravamo noi ad aver ragione.

Io non l'avrei saputo se non fosse stato per Andrea (che ringrazio sentitamente)


 la differenza 



[...]



Non ho neanche letto la solita pappardella boriosa che hai scritto. 

Tagliata di netto. Come ti dicevo: non ti affannare a scrivere. Tanto 

ormai e` chiaro: non sarai mai in grado di rispondere "grazie, oggi ho 

imparato qualcosa". Avrai sempre da ridire con spocchia e arroganza.

Peccato che puntualmente toppi.




 Peccato che puntualmente toppi.





certo che ho imparato qualcosa da te: l'esistenza della metodologia *agile*

e ti ho anche ringraziato, tu non leggi e giudichi? ottimo :-)



magari passa di qui qualcuno curioso, per lui trascrivo la lettera

pubblicata tanti anni fa fa Le Scienze:

--------------------------------------------------------------------

Egregio Direttore, l’articolo di W. Wayt Gibbs,”La cronica crisi del software” (novembre 1994), conferma l’esperienza dei miei 30 anni di lavoro. Per la verità ho fatto software gestionale per medie aziende e non conosco i mega progetti. Ma quando sento parlare di “milioni” di linee, mi viene il sospetto che i programmi siano stati pagati un tanto a riga o che siano stati fatti da incompetenti.

              Ricordo ancora un programma IBM per la consultazione di un data-base gerarchico che, una volta sfrondato delle righe “inutili” si ridusse del 90 per cento. E devo ammettere che i miei programmi più vecchi soffrono di analoghe ridondanze. Quanto più s’impara, tanto più si diventa chiari e concisi. E’ poi ovvio che, meno si scrive, meno si rischia di sbagliare.

              Concordo quindi con Gibbs: valutare il software in base al numero delle righe è fuorviante, non solo per le differenze dei linguaggi, ma anche per il diverso “valore” che le righe possono avere. Il software andrebbe valutato in base a quello che esso “fa”. Purtroppo è più facile contare le righe che dare un voto a ciò che un programma “fa”.

              Quanto ai costi di 700-900 dollari a riga (non so in quale linguaggio), non vorrei che Gibbs si fosse confuso con quello dei tartufi in un anno di magra. E’ vero che i costi crescono con l’esponenziale delle persone coinvolte, ma molto dipende dal fatto che chi fa il programma non sa nulla del problema sottostante.

             Il fatto vero è che il software vien fatto fare agli informatici di primo pelo e si pensa che il software sia un mestiere a sé. Invece  dovrebbe essere uno “strumento” da affidare a persone (necessariamente attempate) che abbiano profonda e globale esperienza d’azienda (o altra organizzazione) e che assumono funzioni organizzative. Naturalmente le applicazioni standardizzabili sono escluse da queste considerazioni. 

             Se quindi concordo con l’autore in merito a quanto dice essere fino ad oggi avvenuto, non credo però possibile “ingegnerizzare” il mestiere, forse perché sono un vecchio “artigiano”. Credo invece che, così come ho suggerito, ci sia modo di farlo molto meglio.

------------------------------------------------------------------------------



quindi, preso atto che la *ingegnerizzazione del software* fù una *pia 

illusione* (parlo di gestionale dove le cose sono fra loro assai 

intrecciate e spesso conflittuali) la metodologia *agile*, se nom 

dispone degli anni necessari affinchè un informatico diventi

discretamente esperto di molte attività aziendali (o viceversa per

insegnare a programmare ad un esperto delle medesime attività) supplisce

nel modo indicato nel link a vikipedia, ma non è la soluzione ottimale: 

mettere assieme più teste è certamente un vantaggio, ma se si esagera 

la confusione può diventare esponenziale



magari Simony si riferiva proprio degli insuccessi della metodologia *agile*

magari Simony dopo il 2010 ha capito cosa mancava a quella metodologia per 

farla funzionare: quanto costa oggi a fare la semplice contabilità di cui

Simony parlava? e funziona bene? Non lo so, ditemi voi



poi francamente non capisco perchè nel 2010 ci fosse ancora bisogno di 

fare software contabile, mi sarei immaginato che a quel tempo, con pochi

pacchetti ben fatti, tutto il mercato contabile sarebbe stato *coperto* 

(salvo le cazzate inventate dai governanti e salvo inevitabili ma marginali 

personalizzazioni)


 magari Simony si riferiva proprio degli insuccessi della metodologia *agile*



No che non si riferiva a quello. Smettila con le tue puttanate e vai a 

studiare, se proprio ci tieni a sapere le cose.


 invasive? retorica.



beh se usi le vecchie versioni (e neanche tanto vecchie, basta prendere 

java 8 prima di una certa release) peggio mi sento. la vm non "onorava" i 

limits impostati tramite cgroup per cui dentro il container la jvm 

pensava di avere tutte le risorse (ram, cpu) dell'host invece di quella 

limitata del container. tipo se avevi un host con 64g di ram e il 

container limitato ad un giga la vm veniva creata di default con un heap 

massimo di 16g (1/4 della ram disponibile) con effetti pirotecnici 

facilmente immaginabili. 


 No che non si riferiva a quello. 

a cosa allora? *tu* hai parlato di *agile*



**********************



non per te che non capiresti (neppure se lo leggessi) trascrivo da un mio libretto l'esemplificazione dei problemi di comprensione che possono 

nascere nella comunicazione utente-informatico; non credo che la metodologia

*agile* li risolva di per sé: va bene fare dei *team*, confrontarsi eccetera, 

a volte occorre proprio *sporcarsi le mani*

------------------------------------------------------



... una mia lettera apparsa su una rivista informatica esemplifica i danni causati dall’oblio del cartello “RIFLETTETE”. Per una miglior comprensione dei non addetti ai lavori, con “carico macchine” s’intende l’insieme dei vari lavori che debbono essere fatti in un reparto produttivo in un intervallo di tempo definito. Ci sono delle ditte che producono piccole serie di prodotti e che molto spesso vengono a sapere quello che la clientela desidera solo all’ultimo minuto. In questa situazione la gestione dell’officina è molto critica: ci si era preparati per fare certe cose e invece i clienti ne vogliono delle altre, in un certo momento ci sono delle macchine sovraccariche e delle altre che non hanno niente da fare, il capo officina vorrebbe “raggruppare” tutta la roba uguale per farla a costi minori mentre i venditori vorrebbero far fare secondo necessità e così via. 



Capite anche voi che è un’ottima situazione per far volare parolacce. Sarebbe molto bello avere un calcolatore che, informato delle richieste dei clienti, delle risorse dell’officina (macchine, operai e alternative varie) e di altre cose ancora, suggerisse, in un baleno, cosa conviene fare: smetti di tornire quel pezzo là e fai questo qui, manda a far fare fuori questo, dì ai venditori che questo si può fare solo la prossima settimana… naturalmente “ottimizzando” tutto in modo da fare il massimo possibile e tacitando le lamentele di chiunque: che bellezza!, che pace! 



E’ un problemaccio, chiamato “capacità finita” (che si può tradurre con: “facciamo quel che possiamo”), dove si fa prestissimo ad avere milioni di alternative da esaminare, ma, nel caso presentato, non si voleva arrivare a tanto: si desiderava estendere certi risultati parziali disponibili per le macchine tradizionali anche ai centri di lavorazione. I “centri di lavorazione” si distinguono dalle macchine utensili tradizionali perché in grado di eseguire molteplici operazioni su di un singolo oggetto e di adattarsi più facilmente a lavorare oggetti diversi: sono molto più elastici delle macchine tradizionali, semplificano la gestione, ma naturalmente c’è un rovescio della medaglia (inoltre l’uomo è bestia insaziabile e vorrebbe sempre moglie ubriaca con botte piena). Sottolineo che anch’io ho fatto brutta figura, non ho fatto un’analisi corretta e non ho riflettuto a sufficienza. Un avvertimento: ho apportato qualche variazione marginale allo scritto apparso sulla rivista per migliorarne la comprensibilità.



       Ho nostalgia del cartello RIFLETTETE (“NEWS 3X/400” Marzo 1993)

Gentilissimo Direttore,…la sua rivista ha già ospitato le mie “eretiche” opinioni; ora è giusto dar spazio ad altri. Avrei tuttavia un esempio reale che spero possa giustificare le opinioni precedentemente esposte. Certo un esempio è poca cosa, non può essere generalizzato. Ma è anche vero che le “teorie” nascono da fatti pratici e nell’esperienza ripetuta trovano la loro verifica. Purtroppo l’informatica non è scienza esatta come la fisica dove la verifica sperimentale è più facilmente eseguibile (mi scusino Galilei e Zichichi per l’intrusione): essa assomiglia di più all’economia dove tutti hanno ragione e tutti torto a seconda dei postulati che vengono posti.   ...

   Ricorderà come la penso: i problemi si risolvono meglio investendo su una corretta ANALISI piuttosto che sull’uso di calcolatori sempre più potenti. Non che la potenza non serva, anzi. Ma se per “convertirmi alla maggiore potenza” non mi restasse più tempo per l’analisi, oppure se ritenessi che la “potenza” consenta di affidare all’utenza la soluzione dei suoi problemi, sarei causa di seri guai.

   Ma veniamo all’esempio: noi abbiamo una procedura (una specie di GANTT che gira su S/36) che usiamo per mettere in fila le operazioni di carico sulle macchine e per calcolarne le date di inizio-fine in funzione dei tempi assegnati e della loro disponibilità (che può variare anche giorno per giorno).

   La nostra procedura, valida per le macchine utensili tradizionali, non era utilizzabile per i centri di lavoro: ritenni infatti di non avere informazioni sufficienti per calcolare le date di inizio-fine dei centri di lavoro poiché, mi dissero, “i tempi di lavorazione variano col variare della composizione delle operazioni in corso a causa di una disponibilità di attrezzatura inferiore al necessario”. 

  A queste parole vidi, mentalmente, il nostro centro più complesso: 3 macchine utensili, ciascuna col suo magazzino di utensili, alimentate da una “giostra comune” con pezzi di vario tipo lavorabili su una o più delle 3 macchine e governate da 3 calcolatori. Io, come hobby faccio il fabbro e “presumevo” d’intendermene, ma mi fermo ad un tornietto del 1937, quindi capirete che la mia competenza era relativa e così confusi gli  utensili (la punta di un trapano, ad es.) con gli attrezzi (che sono quegli aggeggi che tengono fermo il pezzo mentre la macchina lo lavora). Inoltre, per “composizione delle operazioni” l’utente intendeva, forse  spiegandosi male, i diversi pezzi presenti sulla giostra, invece io intesi operazioni come foratura, tornitura, fresatura ecc. 

   Così, sbagliando, pensai che la punta da trapano diametro 30 (ad esempio) potesse servire contemporaneamente a più di una delle 3 macchine, ma che ce ne fosse una sola. Così, sbagliando, immaginai liti fra computer del tipo “dammi la punta del 30!, no, serve a me, fai qualche cosa d’altro intanto che finisco…” e dissi: “Mi pare un bel casino, datemi regole precise e ci proverò, oppure vedete voi se nel mercato del software c’è qualcosa di pronto in materia”. Il tempo passò, regole precise non vennero, né furono trovati pacchetti adatti nonostante le ricerche fatte dall’utenza interessata presso primari fornitori di software ed anche presso istituti universitari.

   Avrete già capito che il problema era, in realtà, banale. Mi direte allora: somaro! perché non sei andato a fondo del problema? Piano. Ricordate la storia dell’uovo di Colombo? Sono poi in buona compagnia, altri specialisti non l’hanno capita, forse credendo d’essere di fronte al ben più complesso problema della “capacità finita”.

   Bene, l’altro giorno ero col gestore del carico d’officina, quando telefona una software-house che propone un mega progetto, fatto con finanziamenti europei, per la gestione d’officina. La telefonata m’induce a chiedere al gestore dell’officina: “Avete poi trovato nulla?”, “No, continuiamo a farlo a mano”, “Ma come fate, tirate a indovinare?”, “No, è un conto preciso”.

   Mi viene freddo: “un conto preciso!?”, ma come? se lo fanno loro, perché non posso farlo io? e così intuisco l’incomprensione e come accontentare l’utenza. 

   Noi emettiamo ordini di lavorazione per “lotti economici” (da poche decine a qualche centinaio di pezzi identici da fare assieme per sfruttare la preparazione delle macchine che li lavorano). Ipotizziamo di dover fare un lotto di 100 pezzi A e un lotto di 50  B. Supponiamo anche che A e B si costruiscano con una sola operazione simile. Usando una macchina tradizionale potremmo  fare, ad esempio, prima tutti i 100 A e dopo i 50 B.

   Se li lavoriamo con un “centro di lavorazione”,  non possiamo lavorare prima tutti gli A e poi  tutti i  B se non abbiamo una “attrezzatura” che consenta di farlo: se ad esempio abbiamo un solo attrezzo per  “fissare” 4 A e uno solo per 10 B e non vogliamo perdere tempo, dobbiamo “mescolare” la produzione degli A con dei B perché il “centro” dovrà lavorare ciclicamente 4 A, 10 B, 4 A, 10 B, e così via  (mentre i 10 B sono in lavorazione, l’operaio smonta dall’attrezzo  i 4 A lavorati prima e monta altri 4 A grezzi …). Quindi lo “attrezzo” condiziona la “cadenza” di lavorazione ma la cosa non ha niente a che fare con gli “utensili” veri e propri (punte, placchette eccetera) e coi “tempi” di foratura, tornitura eccetera.

   Allora per sapere “quando” e “quanti” pezzi verranno fatti, basta suddividere gli ordini di lavorazione così come avviene in realtà: per A  faremo 25 ordini da 4 pezzi e per B faremo 5 ordini da 10 pezzi. Poi (con qualche altra astuzia marginale), basta passare il tutto al solito GANTT e totalizzare le voci uguali che verranno fatte nello stesso giorno (o nel periodo desiderato).

   Il tutto è costato meno di 8 ore di lavoro e non richiede nessun database o client-server o specialissima workstation: bastava solo un po’ di modestia e un pizzico di riflessione.  Morale della favola. L’utente ha detto cose vere, ma non si è spiegato bene e/o io ho capito male: l’attrezzatura condizionava effettivamente la “cadenza” di approntamento dei pezzi, ma non il loro tempo unitario di lavorazione. Certamente ci saranno anche stati problemi all’attrezzatura (nel senso che se si vogliono fare tutti i 100 A senza mescolarli con altra roba e, ovviamente, senza perdere tempo, occorrono almeno 2 attrezzi per lavorare A il che consentirebbe lo smontaggio-montaggio di 4 A intanto che altri 4 A sono in lavorazione) ma sono problemi del tutto irrilevanti per fare il GANTT al quale bisogna dire come stanno le cose e non come sarebbe opportuno che fossero. Se avessi detto: “andiamo in officina e fammi vedere quali sono i tuoi problemi d’attrezzatura”, avrei visto e non mi sarei impantanato.



Se non si conosce il gergo di una professione (e spesso il dialetto del gergo usato in quell’azienda) si rischiano cantonate colossali. Se poi l’utente fosse in grado di fare l’informatico, avrebbe subito detto: “spezza quei documenti e non rompere!”. Quindi non dovrebbe offendersi (come spesso capita) se gli si chiede di verificare le sue affermazioni; spesso la verifica è del tutto inutile, ma lo si sa solo dopo. Avete capito ora perché sostenevo che l’informatico ideale è un ex utente, esperto di molti settori aziendali e lungamente ammaestrato a fare l’analista-programmatore?



In sintesi: l’utenza sa cosa le serve, l’informatico deve capire il problema e poi suggerire come risolverlo. L’OK finale spetta naturalmente all’utente. Ciò non vuol dire che a volte anche l’utenza non possa trovare la soluzione, cosi come anche l’informatico può scoprire bisogni che l’utenza ha coperto col velo dell’abitudine. Ma i ruoli non vanno confusi, altrimenti possono essere guai. Il Sig. Anastasi (era un tale che scriveva lettere a News con tesi opposte alle mie) ha quindi perfettamente ragione quando dice che manca software verticale benfatto e che, quando si fa software su misura, ci dimentichiamo spesso di metterci nei panni dell’utente. Ma ha ragione al 90%: stia ben attento a dosare le risorse fra contenuto e forma. Sappia che un terminalista, dopo che ci ha preso la mano, preferisce avere il massimo dei dati in una sola videata (quindi necessariamente confusa) invece di dover navigare fra numerose videate deliziosamente rifinite e che costano un occhio.  



Per chiudere: l’utente tende a complicare le cose perché mescola i “suoi” problemi (gli attrezzi sono insufficienti) coi problemi realmente informatici (rappresentare la realtà). Se si riesce a mettere veramente a nudo il problema, spesso la soluzione informatica è banale. Ho persino nostalgia di quei famosi e aborriti cartelli con scritto su “RIFLETTETE”. Povero me, mi sono tradito, li hanno smessi almeno vent’anni fa.

---------------------------------------------------------------



una domanda: in JD o in Oracle o in altro, la *capacità finita*, nel tipo

d'azienda prima descritto, ha trovato soluzione? 


 java 8 prima di una certa release)



si ci vorrà java 10 ovunque per ovviare alla "guerra interna" tra jvm e containers per virtualizzare il sottostante. in un universo parallelo una versione più snella di java potrebbe avere in questo senso l'indirizzo architetturale opposto a openjdk (tipo una jikes modificata) ed essere non più gestore di un'intera macchina sottostante. non accadrà mai ovvio.

oggi di fatto il lavoro resta superficiale come nelle build di Zulu, per cui java morirà così: "moderno" architetturalmente. perchè altrimenti dovremmo dire che quello moderno è Go, dati i containers.


 **********************



Ancora che ti affanni co' 'ste robacce? Shift-Page Down, seleziono tutto 

e cancello. Non ti affannare a scrivere.


 Go, dati i containers.



A me non dispiacerebbe affatto usarlo (e difatti me lo sto studiando). A 

me piacerebeb che ci fosse un ecossitema simile a quello di Java 

(sopratutto riguardo a Spring Boot, Spring Cloud)...






 e cancello. Non ti affannare a scrivere.



io sono come Ludovico Antonio Muratori (mio compaesano che ascoltava le 

lezioni del maestro stando accucciato sotto la finestra della squola)

e vorrei imparare, ma se tu non leggi il caso in cui proprio la metodologia

che a me pare *agile* non ha prodotto il risultato atteso, come puoi

redarguirmi ed istruirmi?



Magari  invece di perder tempo con le mie cazzate potresti descrivere un po’

delle tue: intendo i problemi che hai risolto grazie agli imput dei teams che 

teco si relazionavamo, magari proprio la cosa che io non riuscii a fare, cioè 

la programmazione d’officina a capacità finita; 

vero che hai selezionato e cancellato la mia chiara descrizione del problema, 

ma tu  puoi risolvere tutto, anche quello che non conosci 



e qui mi starebbe  per scappare un insulto   :-)  

Cara! 

Rimproverami tu !!! 

E xte dove sei? 

Se anche tua madre fosse stata troppo ottimista sul covid, è in ottima 

compagnia (e poi i conti precisi si potranno fare solo fra qualche mese). 

O mica ti sarai beccato il virus come Boris?


 delle tue



Io non dico e, soprattutto, non faccio cazzate, mi spiace per te. Io, 

poi, devo dar conto alla mia azienda e ai clienti della mia azienda, di 

certo non a te. Io, tutti i giorni, risolvo problemi molto piu` 

complessi di quelli che tu abbia mai affrontanto nei tuoi *tantissimi* 

anni di lavoro. Non perdere tempo. Vai a studiare.


 anni di lavoro. 



ti ho descritto come si poteva risolvere (e risolsi) una roba apparentemente

difficile (a causa dei limiti della metodologia *agile*) e tu non hai

neppure un *titolo* da sbattermi in faccia?



mi sa proprio che conti della balle




 ti ho descritto 



Io non leggo le tue descrizioni perche` non sei informaticamente 

credibile ai miei occhi. Sorry.




Il giorno martedì 26 maggio 2020 11:56:42 UTC+2, 

4ndre4 ha scritto:


invece io mi aspetto che un grande informatico dimostri d'essere tale,

almeno a parole; visto che Simony scrisse nel 2010:

“… ci siamo impantanati … i computer sono migliorati diecimila volte …

eppure … per tradurre in un programma per computer un problema

amministrativo, che si potrebbe descrivere dettagliatamente in cento

pagine, … ci vogliono milioni di dollari e spesso il programma non funziona …”

nel 2010 tu gli avresti potuto risolvere il problema?

cosa lui ti avrebbe dovuto fornire per consentirti di scrivere il software?

quanto tempo ti sarebbe occorso?

quanto gli avresti fatto spendere?

e oggi le cose sarebbero cambiate?

se si, perchè?


 invece io mi aspetto che un grande informatico dimostri d'essere tale,



Nel lavoro di tutti i giorni, non quando si parla con una casalinga di 

Voghera (vicino Modena) :)


 invece io mi aspetto che un grande informatico



PS: io ho scritto di essere un informatico e non ho mai preteso di 

essere un "grande informatico". Le prese per il culo, dal momento che 

non puoi permetterle, visto il basso delle tue conoscenze e della tua 

competenza, tientele per te. Che poi rispetto a te io sia Alan Turing, 

e` un altro conto ;)




 e` un altro conto ;)



quindi tu non saresti in grado di fare la contabilità di cui parla Simony? 

ai miei temmpi la contabilità era la prima cosa che veniva informatizzata

era una roba che non costava certo milioni

e spesso era esente da errori  (faccio un'eccezzione per il pacchetto IBM)

cosa è successo dopo il 2000 che ha reso così complicata questa applicazione?



ma forse tu non ti occupi di gestionale, fai software scientifico?








 ma forse tu non ti occupi di gestionale, fai software scientifico?



Non lo saprai mai.




 Non lo saprai mai.

lavori per la CIA?



ma ora capisco, vedo in 
https://it.wikipedia.org/wiki/Charles_Simonyi


"Nel 1981, su suggerimento di Metcalfe, fece richiesta direttamente a Bill Gates per un lavoro in Microsoft, dove supervisionò lo sviluppo di quelli che sarebbero diventati i prodotti di maggior successo e profitto, Word ed Excel, e del predecessore di Excel Multiplan."

Si tratta di applicazioni *a sè stanti", complicate, difficili, ma non

inserite in una rete complessa e interdipendente come la partita doppia, 

lo MRP eccetera,

Quindi Simonyi non aveva idea di cosa fosse un'applicazione *gestionale*.

Non era dell'Apple, ma era uno che thinkava different :-)

Lui faceva i bugs io no, ma ha avuto ragione lui, 

ha fatto i soldi e ha fatto l'astronauta

si vede che sapeva scaricare le cazzate sue sul suo prossimo

però è strano che continuiate a pendere dalle sue labbra

mi vengono dei sospetti


 ma ora capisco



Ma cosa vuoi capire tu. Il mondo informatico, che tu hai lasciato un 

trentennio fa, e` troppo complesso da capire per te. Ti appigli a 

quattro fesserie e pretendi di capire. Continui a prendere per il culo 

Simonyi, che ti prenderebbe e ti infilerebbe dritto nel suo taschino. 

Certo, puoi farlo perche` qui dentro non ti legge praticamente nessuno. 

Se provassi a dire certe cose all'esterno, verresti seppellito dalle 

pernacchie. "Lui faceva i bugs, io no". LOL :) Lui sapeva come garantire 

che non ve ne fossero; tu no. A giudicare dal numero di volte che lo 

nomini, sei tu quello ossessionato da lui, non di certo io.

Chissa` se certe cose saresti in grado di dirgliele in faccia.


 Chissa` se certe cose saresti in grado di dirgliele in faccia.



Sai come raggiungerlo?

Sai se nei 10 anni successivi ha imparato le tue tecnologie 

e ha così risolto i suoi problemi di allora?



E' solo una curiosità, perchè dal mio punto di vista di pensionato 1995

mi basta aver potuto dire nel 2010: "Allora avevo ragione io" :-)

non si può certo pretendere di aver ragione per sempre 

(ma se s'arrivasse fino al 2020 mica mi farebbe schifo)



Dove ho letto che la vita media del software dovrebbe essere sui 5 anni?

mica ci sarebbe da vergognarsi dall'essere stati superati dopo vent'anni,

ma ci sono cose che permangono: il buon senso e la semplificazione, non

per nulla si continua a citare Occam


   



Esistono fior di prodotti, anche open source, che risolvono il problema.

Prendine uno, integralo nel tuo software, e vendilo a stocazzo.





-- 

The three most dangerous things in the world are a programmer with a 

soldering iron, a hardware type with a program patch and a user with an 

idea.



“Alles hat ein Ende, nur die Wurst hat zwei”


 per nulla si continua a citare Occam



Il buon senso (che tu non hai, senno` avresti smesso di scrivere tempo 

fa) e la semplificazione (che tu non comprendi perche` i tuoi "rimedi" 

complicano piu` che semplificare) non bastano, quando cio` che serve e` 

conoscenza, competenza ed esperienza. Tu non possiedi niente delle tre. 

Lo hai dimostrato.


 Prendine uno, integralo nel tuo software, e vendilo a stocazzo.



Oltre al fatto che esistono efficientissimi sistemi di ottimizzazione 

dei processi produttivi. Io ho lavorato su questo: 

https://www.fico.com/en/products/fico-xpress-optimization




Ovviamente lui, al solito, portera` la discussione dove vuole lui, con 

Simonyi, IBM, JD, "il dottore", il millennium bug e le solite stronzate.




 Prendine uno, integralo nel tuo software, e vendilo a stocazzo.



ne ho aperto uno a caso

https://www.smeup.com/blog/blog-software-gestionali-erp/mrp-a-capacita-finita/


Un vantaggio importante dell’MRP a capacità finita è l’adattabilità. Questo è infatti facilmente adattabile alle esigenze specifiche di ogni cliente, in modo che possa eseguire i processi usuali di produzione.  La struttura dei gruppi fonte permette infatti di selezionare facilmente quali giacenze includere e quali no, permettendo di ottenere una vista come fabbisogno negativo. In questo contesto, l’MRP è in grado di fornire una vista, detta CAP, che include tutto ciò che è necessario produrre per attuare il piano di spedizione per capacità delle risorse. Nello sviluppo dei suggerimenti di produzione, l’MRP calcolerà il fabbisogno derivante dalla vista CAP sugli ordini di produzione già rilasciati e produrrà solo le quantità mancanti necessarie.



questa è solo l'inizio della fola

ma bisogna riferirsi al caso concreto (che il dottore conosce)



Il tuo problema è che uno schedulatore a capacità finita tu non lo 

sapresti usare. Hai la testa troppo piena delle tue pluridecennali 

teorie bislacche per potere comprendere qualcosa di appena più complesso 

di un peto.



 Un vantaggio importante dell’MRP a capacità finita è l’adattabilità. 



Tie`, vattelo a studiare. Ci ho lavorato per 3 anni sui prodotti Xpress 

(anche se non ho mai amato molto Mosel come linguaggio):



https://www.maths.ed.ac.uk/hall/Xpress/FICO_Docs/Xpress-booka4.pdf




Come gia` detto altrove, non ti spremere le meningi. Non sarai mai in 

grado di comprendere alcunche` di ricerca operativa.


 sapresti usare.



Guarda che ti sbagli. Lui ha il "buon senso" dalla sua.




 > per nulla si continua a citare Occam



pensa che per la paura che tu andassi a rivedere le bucce al mio abbozzo

sull'evoting, lo sono andato a rimaneggiare e mi pare proprio d'averlo

semplificato; involontariamente mi sei stato utile: grazie




 semplificato



La merda semplificata sempre merda rimane.




 
https://www.maths.ed.ac.uk/hall/Xpress/FICO_Docs/Xpress-booka4.pdf




ho guardato la casistica, sembra roba banale;

sto parlando di situazioni in cui il programma non è totalmente compatibile

con la situazione magazzini

con gli impegni e gli ordini in corso

col calendario d'officina

col parco macchine esistente

col rendimento delle medesime

con la disponibilità di personale

coi parametri gestionali

coi cicli standard (esistendo varie alternative compreso il riscorso 

    a una o più lavorazione esterne (robe difficicilmente parammetrizzabili)

con il grado d'incazzabilità dei clienti eventualmente da scontentare

con .... un sacco di altre robe



noi si faceva un giro di MRPII e si vedeva che succedeva

visti i problemi si apportavano ipotetiche modifiche qua e là (a buon senso)

poi si rigirava e si vedeva il risultato

questo più volte fino a che non si arrivava a un buon compromesso realizzabile



la capacità finita che si desiderava (invano) era qualcosa che facesse 

tutto questo quasi istantaneamente e automaticamente all'arrivo di ogni 

ordine dei clienti ottimizzando il tutto :-)



mica producevamo robe semplici in grande quantità



ho giusto trovato copia della documentazione,

quando avrò tempo la scannerizzerò a futura memoria (certo non vostra)

devo ammettere che a quei tempi (circa il 1991) i mezzi grafici a mia

disposizione erano assai brutlazzi, ma ci si contentava 



sono molte pagine, ecco la prima 

(descrive sinteticamente collegamenti e operazioni)

https://digilander.libero.it/gino333/MRP-1.jpg



 Boeing e magari all'astronauta



Boeing è un player come tanti. Semmai studia tu lo stato dell'arte e miglioralo.



ad es. 
http://www.astree.ens.fr




e vd. bibliografie

https://en.m.wikipedia.org/wiki/Astrée_(static_analysis)


 ho giusto trovato copia della documentazione,



Ma quale documentazione. Giacche` ci sei, ai tuoi nipoti stampa pure le 

conversazioni qui dentro e lasciagliele a futura memoria. Vedrai che bel 

ricordo del nonno avranno.


 https://en.m.wikipedia.org/wiki/Astrée_(static_analysis)



Ma va`, e` roba banale. Lui ha il buon senso che lo guida nei suoi 

tentativi. D'altronde, basta far cadere un po' di aerei, un po' di 

volte, e poi un compromesso accettabile lo si trova.


 senso che lo guida nei suoi tentativi. 



risolve pure le combinazioni strane non testate in ambito industriale meglio di un sat solver. col culo però


 non "perfetto", rispondente ad una data specifica formale.



tu credi che un programma che ha superato indenne astree

sia più esente da bugs e più rispondente allo scopo per cui è stato scritto

di un altro programma inserito in una procedura di decine di programmi

che funziona senza intoppi da una decina di anni?



può benissimo essere, complimenti ad astree,

se poi dici "non perfetto* sono anche contento

perchè anche i miei metodi non potevano garantire la perfezione assoluta

(come già detto, solo appannaggio della qualità totale che arrivava, ai miei

tempi, al 102-103% di perfezione, chissà ora, sarà sarà al 120-130%)






 Infatti producevi merda in grande quantita`.



a uno che scrive come te non si dovrebbe rispondere

verissimo che ho dato solo un'occhiata (si stava litigando su altra

tipologia di software) comunque la prima occorrenza è:



8.3 we plan the production of toy lorries with all their components. This is a typical case of Material Requirement Planning (MRP). 

camion giocattolo!

vai a vedere quali dati usano e vedi se si assomigliano a quelli citati

nel mio foglio (che non hai certo guardato)

8.3 richiamato pure a pag 120 (roba IBM anni 70, che usavo anch'io)

a parte la banalità dell'oggetto

non vedo giacenze di magazzino, impegni, ordini di magazziono,

ordini clienti, previsiopni di vendita, calendario d'officina, 

parco macchine, loro rendimento,cicli di lavorazione, alternative di

lavorazione, lotti economici, tempi di approvigionamento ... non vedo 

le correlazioni con le altre gestioni aziendali interconnesse ...



mrp e materials requirements planning sono citati solo in 2-3 punti

stiamo parlando di robe diverse



comuque grazie per avermi fatto capire che ciò di cui si lamentava

l'astronauta (che passanddo da Word-Excel all'Arte e alla beneficenza

non doveva saperne molto di gestionale) si riferiva ad una situazione

generale valida almeno fino al 2010: una semplice applicazione

amministrativa (non più precisamente descritta) spesso non funzionava 

bene pur essendo costata milioni. Resto con la curiosità di sapere se 

questo è ancora vero oggi



ciao e vai a spargere merda più lontano da me


 se poi dici "non perfetto* sono anche contento 



no, sei ignorante. ci sono precisi motivi di teoria della ricorsione per quello e che tu ovviamente non conosci. 


 non "perfetto", rispondente ad una data specifica formale.

tu credi che un programma che ha superato indenne astree

sia più esente da bugs e più rispondente allo scopo per cui è stato scritto

di un altro programma inserito in una procedura di decine di programmi

che funziona senza intoppi da una decina di anni?

-------------------------------------------------

potevi rispondere dando la preferenza a una delle due ipotesi



ciao


 complessita`, semmai, e` data dalla burocrazia che ci sta dietro, 



92 minuti di applausi.



Sto dando una mano a un'azienda che fa principalmente software gestionale, ed è di un palloso da paura (anche se stiamo usando web services).



-- 

Ciao!

Luca


 per IBM nel 1995 era un problema difficile, 



Vediamo. Nel '95 facevo software per grafica industriale applicata all'industria tessile; specificamente, campionature su carta con fedeltà tessuto e produzione di lucidi per fotoincisione.



Credi, il software gestionale NON E' complesso per definizione.



-- 

Ciao!

Luca


 ci sono miliardi di cose che tutti non conosciamo poichè 



blablablabla...



ginè, non sai di che cazzo stiamo parlando, le tue due "ipotesi" sono due cazzate e il modo in cui poni i confronti è ridicolo. tu le chiami offese, io matematica. fai te


 ci sono miliardi di cose che tutti non conosciamo



e tra queste non intuire che si sta andando verso il subsuming dell'halting problem e non saper formulare e usare teorie e linguaggi adatti a verificare, ha il suo peso specifico ben diverso dagli altri miliardi di cose che tu pensi siano importanti. soprattutto se ti lanci a parlare di correttezza a tutto pene di segugio. 



e riguardo alle due tue "ipotesi", il confronto non sussiste nemmeno.


 Credi, il software gestionale NON E' complesso per definizione.



d'accordissimo, difatti il 27 ho scritto:

-----------------------------------------------------

per IBM nel 1995 era un problema difficile, non per me (nè per molti)...

-----------------------------------------------------

a conferma (oltre a quanto disse il dottore molto fa) ti racconto

che prima del 95, in una conferenza dove IBM pubblicizzava il suo

ultimo pacchetto contabile, chiuse in bellezza affermando d'essere

in grado di correggerne gli errori via telefono !!! :-)

non mi ricordo bene, ma nel 78 l'ORGA aveva fatto installare il

precedente pacchetto IBM (sul 34) che appena potei sostituii con roba 

mia, direi perchè ogni tanto, non so come, Dare e Avere non quadravano :-)



ciao


 mia, direi perchè ogni tanto, non so come, Dare e Avere non quadravano :-)



Secondo me sei anche bugiardo. Vorresti dire che il tuo "pacchetto" era 

migliore di ADM della IBM? Il tuo "pacchetto", mica pizza e fichi! Dare 

e Avere con IBM non quadravano???? Ma vai a cacare, vai.



-- 

The three most dangerous things in the world are a programmer with a 

soldering iron, a hardware type with a program patch and a user with an 

idea.



“Alles hat ein Ende, nur die Wurst hat zwei”


 e mi viene da ridere quando l'IBM presentando le sue meravigliose ACG ...

Delle ACG si puo' dire tutto ma non che fossero meravigliose, concordo.

Ma hai citato l'esempio giusto di come un software antico, mai adeguato

dal punto di vista tecnologico, si e' rivelato inadeguato ed

insostenibile anche dal punto di vista applicativo, stante anche gli

abnormi costi di sviluppo e manutenzione che hanno portato IBM Italia,

forzata da IBM USA, a disfarsi del ramo d'azienda con centinaia di

addetti inclusi.

Ti ricordo che le ACG derivavano direttamente dalla pedissequa

conversione delle ADB del s38, conservando RPGIII - che praticamente era

gia' obsoleto all'annuncio - che a loro volta 'prendevano spunto' dalle

ADM del s34/36. Facile verificarlo dalle righe di sorgente, alcune delle

quali riportano date risalenti a quando io avevo appena smesso le braghe

corte.

E c'erano tutte quelle cosine che piacciono a te, come la routine di

conversione delle date, le date numeriche invece di date tipizzate

(almeno quelle erano a 8 cifre), i famigerati 'file tabelle', l'assenza

di relazioni e vincoli di data-base, gli array a dimensione fissa, sort

a runtime, assenza della gestione dei campi NULL (qualsiasi valore null

risultante dalla lettura dal data-base faceva scoppiare qualsiasi tra le

migliaia di programmi), etc.etc.etc.etc.etc.etc.etc.etc., e chi piu' ne

ha piu' ne metta ...

------------------------------------------------------------------



poi che anche nel 2010 ci fosse chi faceva casino con roba

amministrativa lo dice Simony (probabilmente si trattava di

roba in tempo reale: funzione ramente utile in quell'applicazione)



cazzo! centinaia di addetti per le ACG? non ci avevo fatto caso :-)



ciao e vai a cacare altrove




 



Masochismo ?



 Masochismo ?



in effetti fu poi il capo amminiotrativo che scelse JD :-)

(visto che il filopacchettaro se la fece sotto)

ma ora mi viene in mente cosa succedeva col vecchissimo pacchetto IBM:

si riuscivano ad inserire le contropartite senza quadrare con la partita

magari c'era un avvertimento, però i pistoli si trovano sempre



tornando all'ultimo casino udito per gli aerei: se ben ricordo

il pilota automatico fu ingannato da un sensore rotto che dava informazioni

sbagliate; non s'è capito se il software non permetteva di farsi bypassare

dai piloti o se i piloti hanno dormito. Chissà se *astree* queste cose le

considera



quanto al dottore che il titolo: "Selmi colpisce ancora: crisi di unuomo EDP 

di fronte al CASE" lo considera come una presa per il culo (a differenza di 

un calcistico "Rivera colpisce ancora: segna due gol...") noto che era sì

preceduto da un milanese che riteneva (contrariamente alle mie affermazioni)

più comodo l'AS/400 del 36 nella gestione dello spool, ma era seguito da una 

lettera intitolata dalla rivista "E dal Texas arriva un quiz SSP e DOS in 

aiuto alle tesi di Selmi" 





Secondo me non ti capisci nemmeno tu.



 altrimenti perchè l'amministratore accettò la mia versione?



questa la so!

è perchè te gli facevi nascondere il nero.








 è perchè te gli facevi nascondere il nero.



vuoi ridere?

al tepo degli UR (1968-69) in un centro di Parma c'erano varie cassettiere:

PAGHE, MAGAZZIO, CONTABILITA', NERO ...

scritte proprio a pennarello su etichette bianche appiccicate ai cassetti


 vuoi ridere?



mica scherzo. lo so perché agli amministrativi piace avere lo 

sviluppatore a disposizione, tengono famiglia.


 sviluppatore a disposizione, tengono famiglia.



se vuoi essere serio, no, non ho mai trafficato per il nero






 comuque grazie per avermi fatto capire



Ma cosa vuoi capire tu. In ogni post che scrivi dimostri che tu e 

l'informatica non potreste essere piu` distanti di quanto siate.



La merda la stai spargendo TU, non io, e da tempo. Vedi di darci un taglio.




 perchè anche i miei metodi non potevano garantire la perfezione assoluta



La perfezione assoluta non esiste. Esiste la rispondenza di un software 

ai requisiti del cliente. E quei requisiti si possono formalizzare. E si 

possono validare. Tutte cose che non hai mai fatto e che non sapresti 

fare. Altro che contento. Dovresti essere triste al pensiero di quanta 

roba non conosci.


 il tuo termine *ignorante* è inappropriato e volutamente offensivo



Appropriatissimo e constatante la realta`.


 decina d'anni non prova un bel di niente.



c'è chi si accontenta


 c'è chi si accontenta



Certo, ma non deve lamentarsi se poi gli si da` del peracottaro.




 Certo, ma non deve lamentarsi se poi gli si da` del peracottaro.



innanzitutto quello del peracottaro è un nobile mestiere (se le pere sono

buone e adatte), poi la tua arte è certamente successiva al 2010 quando

l'astronauta scriveva:

 “… ci siamo impantanati … i computer sono migliorati diecimila volte …

   eppure … per tradurre in un programma per computer un problema

   amministrativo, che si potrebbe descrivere dettagliatamente in cento

   pagine,…ci vogliono milioni di dollari e spesso il programma non funziona…” 

non mi dirai che l'astronauta non conoscesse l'ultimo grido dell'informatica

di quei tempi lontani! perciò, essendomi io fermato per lo meno al 2000,

mica sono tenuto tenuto ad essere à la page,

ed è da un po' che chiedo cos'è successo dopo il 2010 (circa)

ma mi dici che non sarei in grado di capire :-(



comunque io ero in grado di fare, e senza marroni evidenti



al forno sono buone anche le mele lavine! sai?


 comunque io ero in grado di fare, e senza marroni evidenti



Tu non eri in grado di fare un bel niente, e lo hai dimostrato. Facevi 

cappelle; riprovavi; facevi cappelle meno evidenti; riprovavi; facevi 

cappelle un pochino meno evidenti e le vendevi come risultato 

accettabile. Certo che se ti convinci che i tuoi bug sono feature, il 

tuo software avra` solo feature e niente bug. Un peracottaro 

(figurativo) appunto. L'assenza di marroni non sei mai stato in grado di 

provarla. E il bello e` che pensi che riuscire a provare l'assenza di 

bug in certi algoritmi significhi garantire la "perfezione assoluta". 

Sei un peracottaro (figurativo), appunto :)


 risolti.



alla buon'ora! ci voleva tanto? grazie:

fino ai tempi in cui l'astronauta scriveva (circa il 2010) 

i problemi c'erano,

problemi che io non ho mai avuto, 

quindi Greco non mi prendeva per il culo dicendo che io ero stato un genio



se poi non riesco a capire come avete rimediato dopo il 2010

mi rassegnerò :-( 

mica posso pretendere d'essere pietra di paragone in eterno



e ora vai a contare cazzate allo specchio, che lui forse ti sopporta 


 e ora vai a contare cazzate allo specchio, che lui forse ti sopporta



Selmi, le cazzate, e da mesi, le stai contando tu, non io. Adesso 

piantala con la tua montagna di stupidaggini.