Software Development for Dummies

Al momento mi posso definire full stack developer visto che sto lavorando su un progetto dove mi occupo del backend e anche della rappresentazione dei dati.
Come detto da altri la creazione di un software non parte mai da zero ma sfrutta ampiamente cose già sviluppate e funzionanti, anche se ogni tanto l’ansia da pagina bianca c’è sempre.

Comunque credo che uno dei pro di questo tipo di lavoro è che ti porta a stare sempre aggiornato su ogni nuova tecnologia che ti può essere utile e quindi di non fossilizzarti su una sola cosa.

Approfitto del topic per chiedere se avete mai usato i database non relazionali tipo MongoDb? Vale la pena studiarli?
Studiarli no, usarli si. Fidati, mentalmente parlando, sono una stupidata che uno puo' complicare all'inverosimile.. tira un docker container nel terminale, copia incolla un paio di commandi per inserire dati, e sai gia' meta' di quello che devi sapere. poi guardati i docs se vuoi capire le differenze tra le varie db ed i contesti dove potresti usare uno contro un altro, ma moooolto dopo.
 
rispondo a te ma vale per tutti

non e' necessariamente corretto cominciare a ragionar per algoritmi, anzi, secondo me e' proprio errato.
si ragiona per "come intendo modellare il mondo?"
un approccio algoritmico era valido 20 anni fa, oggi non ha piu' alcun senso.

20 anni fa si doveva ragionare su strutture dati (code, liste, doppie liste, ...), su sorting, su un sacco di roba che ha completamente perso di significato

esattamente come 150 anni fa si usava il regolo calcolatore e si facevano le radici quadrate carta e penna.

ogig per cominciare a programmare si deve ragionar in modo completamente diverso, dimenticandosi degli aspetti algoritmi, sintattici, che arrivano da soli, con tempo e esperienza.

E' invece importante capire le filosofie degli strumenti (non linguaggi ma framework, filosofie di design, ...) e poi tutto viene dopo.

Per fare un esempio pratico, se oggi vuoi fare applicazioni mobile e decidi di usare flutter (esempio proprio a caso) la cosa peggiore che puoi fare e' studiare dart, e poi flutter e poi capire come sono strutturate le applicazioni ecc ecc, cioe' totalmente bottom up
Si deve fare esattamente il contrario, devi capire come si struttura una applicazione ad alto livello, e poi come ne disegni i componenti, ecc ecc, fino ai livelli piu' bassi che coinvolgono il linguaggio.
Ma gli algoritmi non servono a un beato ***** oggi, perche' non ti metti tu a scrivere map/reduce/filter/sort/reverse/... e' tutto pronto, come lo e' la radice quadrata nella calcolatrice. Se parti dagli algoritmi, arrivi dopo la prossima vittoria dello scudetto del milan.

Programmare ti aiuta a imparare a pensare.
Implementare algoritmi significa che tu pretendi di sapere pensare prima di imparare, e' errato.

p.s. e' errato oggi ... 40 anni fa esistevano 3/4 linguaggi (basic, cobol, fortran. c, e poco altro) senza alcun supporto. Dovevi procedere cosi', perche' le risorse erano limitate, il mio primo computer aveva 16kb ram, e io scrivevo applicazioni CAD su workstation (costosissime) con 1mb di ram, sviluppavo applicazioni DB3 per pc con 128kr ram tipo olivetti m24 e ibm xt e simili, era un mondo differente. oggi e' tutto tutto diverso.
mmmm nì

nel senso, capisco cosa vuoi dire e sono pure d'accordo
però
se ci pensi
nel contesto didattico di quell'esercizio che stava facendo eug90
il suggerimento di riprenderlo facendo un passo indietro e ragionandoci come algoritmo/pseudocodice - partendo da un pezzo di carta e anche "in italiano" come suggeriva giustamente Cirano - era esattamente nel senso di avere un approccio top-down invece che bottom-up, proprio secondo il concetto che "programmare ti aiuta a imparare a pensare".
 
mmmm nì

nel senso, capisco cosa vuoi dire e sono pure d'accordo
però
se ci pensi
nel contesto didattico di quell'esercizio che stava facendo eug90
il suggerimento di riprenderlo facendo un passo indietro e ragionandoci come algoritmo/pseudocodice - partendo da un pezzo di carta e anche "in italiano" come suggeriva giustamente Cirano - era esattamente nel senso di avere un approccio top-down invece che bottom-up, proprio secondo il concetto che "programmare ti aiuta a imparare a pensare".
che e' corretto, nel modo classico.
programmare significa prima di tutto astrarre e modellare

ma oggi e' complicato astrarre, un volta era semplice perche' sotto di te avevi solo il linguaggio, ora hai montagne di strumenti e se stai solo al livello del linguaggio e' un po come studiare il movimento della terra analizzando i quanti di cui e' composta. lo puoi fare ... ma non ci arrivi mai.
ora hai tonnellate di strati, in quantita' impossibile, e partire dal linguaggio e' un modo di imparare che non funziona piu' (o meglio, funziona ma e' impraticabile), ti arrendi prima di arrivare al risultato.

voglio precisare, quello che racconta cirano io lo ho raccontato per una vita, non e' per nulla errato. ma il mondo IT e' cambiato in modo immenso, e con il mondo IT anche le metodologie di insegnamento e apprendimento sono cambiate.

Aggiungo un pezzo. Quando si dice "implementa questo algoritmo, anche in italiano", sempre come dice correttamente cirano, si prende per scontato di ragionare in modo imperativo. Che e' solo uno dei modi con cui puoi risolvere un problema o modellare il mondo. Perche' non in modo funzionale? perche' non in modo object oriented?
Ormai i linguaggi imperativi non sono i soli linguaggi (anzi, stanno perdendo enormemente di importanza). prima bisogna imparare a pensare in modo adeguato alle teconlogie che intenderai usare. E solo dopo scendere al livello del linguaggio, oppure verament non ne esci piu', una volta imparata una banale sintassi e un modo di pensare qualunque sia, poi non riesci ad applicarlo mai.
 
Ultima modifica:
cosa succede per un numero negativo?
Nella divisione un numero negativo equivale alla moltiplicazione quindi: (-) * (-) = +
(+) *(-) o (-) * (+) = -

Comunque io parto sempre da 1 se voglio un numero primo, che di solito sono positivi e non ho mai sentito di numeri primi negativi.
 
Ultima modifica:
mmmm nì

nel senso, capisco cosa vuoi dire e sono pure d'accordo
però
se ci pensi
nel contesto didattico di quell'esercizio che stava facendo eug90
il suggerimento di riprenderlo facendo un passo indietro e ragionandoci come algoritmo/pseudocodice - partendo da un pezzo di carta e anche "in italiano" come suggeriva giustamente Cirano - era esattamente nel senso di avere un approccio top-down
invece che bottom-up, proprio secondo il concetto che "programmare ti aiuta a imparare a pensare".
Mmmhhh quindi mi stai suggerendo di dividerlo in sottoprogrammi?
 
che e' corretto, nel modo classico.
programmare significa prima di tutto astrarre e modellare

ma oggi e' complicato astrarre, un volta era semplice perche' sotto di te avevi solo il linguaggio, ora hai montagne di strumenti e se stai solo al livello del linguaggio e' un po come studiare il movimento della terra analizzando i quanti di cui e' composta. lo puoi fare ... ma non ci arrivi mai.
ora hai tonnellate di strati, in quantita' impossibile, e partire dal linguaggio e' un modo di imparare che non funziona piu' (o meglio, funziona ma e' impraticabile), ti arrendi prima di arrivare al risultato.

voglio precisare, quello che racconta cirano io lo ho raccontato per una vita, non e' per nulla errato. ma il mondo IT e' cambiato in modo immenso, e con il mondo IT anche le metodologie di insegnamento e apprendimento sono cambiate.

Aggiungo un pezzo. Quando si dice "implementa questo algoritmo, anche in italiano", sempre come dice correttamente cirano, si prende per scontato di ragionare in modo imperativo. Che e' solo uno dei modi con cui puoi risolvere un problema o modellare il mondo. Perche' non in modo funzionale? perche' non in modo object oriented?
Ormai i linguaggi imperativi non sono i soli linguaggi (anzi, stanno perdendo enormemente di importanza). prima bisogna imparare a pensare in modo adeguato alle teconlogie che intenderai usare. E solo dopo scendere al livello del linguaggio, oppure verament non ne esci piu', una volta imparata una banale sintassi e un modo di pensare qualunque sia, poi non riesci ad applicarlo mai.
Tutto giusto, ma qui si sta parlando di persone che devono partire da 0 ovvero non hanno mai scritto neanche 1 linea di codice e non sanno cos'è if-else, while, for ecc

Io programmo funzionale/oggetti in Scala ma a una persona alle prime armi, cioè che parte proprio da 0, non consiglierei mai di partire subito con la programmazione funzionale

Almeno una passata sulle cose base deve essere fatta imho
 
Alto