Ho iniziato l'università ma non riesco a programmare

Pubblicità
Perché parlare di aria fritta?
Qui il punto è un altro: il professore dell'utente che ha aperto la discussione ha deciso per Python, quindi possiamo stare a discutere fiché volete, ma l'utente deve imparare a programmare usando Python come mezzo.

Sul Pascal sono d'accordo con @gronag e l'ho ribadito in più di una occasione (ha tutto ciò che serve, puntatori compresi, senza essere diabolico come il C per chi inizia).
Riguardo Python, nei corsi introduttivi viene insegnato ma spesso non si arriva alle classi: in pratica viene usato come linguaggio che dà poche preoccupazioni, concentrandosi (giustamente) solo sulla logica di programmazione. Le classi di Python spesso si lasciano stare, non vengono trattate, rimandandole a quando si affrontano C++ o Java.
Per quanto riguarda i tipi di dato, erano e rimangono fondamentali; le classi poi, detto in parole poverissime, sono una generalizzazione di "tipo" (programmato da utente).
 
Hai detto che alcune cose le hai capite: bene, parti da quelle!

Probabilmente ad oggi sai scrivere e compilare un programma in Python. Probabilmente hai studiato e (almeno in parte) compreso i cicli e ciò che ci puoi fare. Hai compreso il funzionamento di alcune funzioni di libreria. Benissimo! Questi sono i mattoncini di base che ti permetteranno SEMPRE di risolvere i problemi legati alla programmazione.

Ora facciamo un attimo un passo indietro: che cosa richiedono i problemi? Richiedono, prima della stesura stessa del codice, di comprendere e risolvere un problema LOGICO: spegni il PC e risolvi il problema prima a livello logico, quindi torna al PC e pensa a come poter scrivere la soluzione che hai già trovato.
 
Hai detto che alcune cose le hai capite: bene, parti da quelle!

Probabilmente ad oggi sai scrivere e compilare un programma in Python. Probabilmente hai studiato e (almeno in parte) compreso i cicli e ciò che ci puoi fare. Hai compreso il funzionamento di alcune funzioni di libreria. Benissimo! Questi sono i mattoncini di base che ti permetteranno SEMPRE di risolvere i problemi legati alla programmazione.

Ora facciamo un attimo un passo indietro: che cosa richiedono i problemi? Richiedono, prima della stesura stessa del codice, di comprendere e risolvere un problema LOGICO: spegni il PC e risolvi il problema prima a livello logico, quindi torna al PC e pensa a come poter scrivere la soluzione che hai già trovato.
I classici algoritmi :D
 
Senza algoritmo è praticamente impossibile stilare un codice, di qualsiasi linguaggio!

Esattamente come nel caso della progettazione di un database … prima c'è la fase della modellazione concettuale … poi si passa alla fase della modellazione logica … ah ah ah … relazionale … non si può "saltare" il livello concettuale … i diagrammi E/R e UML … ah ah ah … :D
 
Esattamente come nel caso della progettazione di un database … prima c'è la fase della modellazione concettuale … poi si passa alla fase della modellazione logica … ah ah ah … relazionale … non si può "saltare" il livello concettuale … i diagrammi E/R e UML … ah ah ah … :D
Già! Il codice è completamente sconfusionato senza una progettazione di un algoritmo a monte :D
 
Senza algoritmo è praticamente impossibile stilare un codice, di qualsiasi linguaggio!
Assolutamente NO. Quello era vero una volta, quando si parlava in termine di "algoritmi" che era in pratica sinonimo di "algoritmi matematici", utili appunto a risolvere un problema matematico. Si "traduceva" un problema in numeri e vettori capaci di memorizzarli, e si scriveva un algoritmo. Tipo il Bubble Sort.
Adesso le cose sono cambiate parecchio. Usiamo linguaggi di alto livello, non stiamo piu' a reinventare la ruota. Il Bubble Sort lo impariamo a scuola, ma poi quando andiamo a lavorare il nostro manager ci licenzia in tronco se scriviamo un Bubble Sort di nostro pugno, per lo stesso motivo che non scriviamo il nostro compilatore e il nostro sistema operativo.
Ormai chi scrive algoritmi sono ben poche persone, principalmente a livello accademico. Chi lavora deve affrontare un problema reale, deve trovare gli strumenti piu' adatti per risolverlo. Per esempio, progettare e poi ottimizzare le tavole di un database per ottimizzare il tempo di richiesta da parte di un utente.
 
Assolutamente NO. Quello era vero una volta, quando si parlava in termine di "algoritmi" che era in pratica sinonimo di "algoritmi matematici", utili appunto a risolvere un problema matematico. Si "traduceva" un problema in numeri e vettori capaci di memorizzarli, e si scriveva un algoritmo. Tipo il Bubble Sort.
Adesso le cose sono cambiate parecchio. Usiamo linguaggi di alto livello, non stiamo piu' a reinventare la ruota. Il Bubble Sort lo impariamo a scuola, ma poi quando andiamo a lavorare il nostro manager ci licenzia in tronco se scriviamo un Bubble Sort di nostro pugno, per lo stesso motivo che non scriviamo il nostro compilatore e il nostro sistema operativo.
Ormai chi scrive algoritmi sono ben poche persone, principalmente a livello accademico. Chi lavora deve affrontare un problema reale, deve trovare gli strumenti piu' adatti per risolverlo. Per esempio, progettare e poi ottimizzare le tavole di un database per ottimizzare il tempo di richiesta da parte di un utente.
Ok ok. Grazie della spiegazione. Io sono rimasto a 12 anni fa quando uscì dalle superiori e quindi non mi sono più informato nei linguaggi di programmazione moderni...
 
… non si può "saltare" il livello concettuale … i diagrammi E/R e UML …
Scusa se mi intrometto, ma quello che hai citato ha ben poco a che fare con la programmazione.
Un diagramma ER (Entity Relationship Diagram) viene usato per progettare le tavole per un database di tipo relazionale. In pratica definisce le ralazioni tra i tipi di dati.
UML (Unified Modeling Language) viene usato (pochissimo) per progettare un intero prodotto, non solo la parte software. Viene usato principalmente in grosse aziende per grossi progetti, dove nella fase di progettazione i programmatori non sono neanche presenti, bensi' una vasta serie di divisioni molto variegate (tipo ricerca, ingenieria, marketing, finanze, saleforce e cosi' via). Per progetti piccoli, e' come uccidere una mosca con un cannone.
Se siete interessti potremmo parlarne in una discussione separata.
 
Assolutamente NO. Quello era vero una volta, quando si parlava in termine di "algoritmi" che era in pratica sinonimo di "algoritmi matematici", utili appunto a risolvere un problema matematico. Si "traduceva" un problema in numeri e vettori capaci di memorizzarli, e si scriveva un algoritmo. Tipo il Bubble Sort.
Adesso le cose sono cambiate parecchio. Usiamo linguaggi di alto livello, non stiamo piu' a reinventare la ruota. Il Bubble Sort lo impariamo a scuola, ma poi quando andiamo a lavorare il nostro manager ci licenzia in tronco se scriviamo un Bubble Sort di nostro pugno, per lo stesso motivo che non scriviamo il nostro compilatore e il nostro sistema operativo.
Ormai chi scrive algoritmi sono ben poche persone, principalmente a livello accademico. Chi lavora deve affrontare un problema reale, deve trovare gli strumenti piu' adatti per risolverlo. Per esempio, progettare e poi ottimizzare le tavole di un database per ottimizzare il tempo di richiesta da parte di un utente.

Facciamo finta di non ricordare che al primo posto della classificazione ACM dei settori disciplinari relativi all'informatica professionale ci siano gli algoritmi e le strutture dati, un problema di qualsiasi natura, non solo matematica, dovrà essere analizzato prima di poter essere risolto o no ? :skept:
Quindi l'algoritmo è un concetto "primitivo" fondamentale nell'informatica, poi posso convenire con te sul fatto che oggi la professione di informatico sia diventata multiforme e che lo stesso modo di programmare si sia "diversificato" nel corso degli anni ma non facciamo passare l'idea sbagliata che per ottenere un determinato risultato non occorrano procedure "sistematiche" ;)
Non è una questione puramente informatica (o matematica) :)
 
Comunque reputo lo studio degli algoritmi essenziale per qualsiasi sviluppatore, poiché senza la loro conoscenza non si possono utilizzare con coscienza... Lo vedo ogni giorno a lavoro, quando i colleghi usano algoritmi e pattern a caso senza accorgersi che potevano svolgere la stessa cosa con algoritmi e pattern semplicemente migliori per il dato problema

Sent from my ONEPLUS A5000 using Toms Hardware Italia Forum mobile app
 
Ultima modifica:
Scusa se mi intrometto, ma quello che hai citato ha ben poco a che fare con la programmazione.
Un diagramma ER (Entity Relationship Diagram) viene usato per progettare le tavole per un database di tipo relazionale. In pratica definisce le ralazioni tra i tipi di dati.
UML (Unified Modeling Language) viene usato (pochissimo) per progettare un intero prodotto, non solo la parte software. Viene usato principalmente in grosse aziende per grossi progetti, dove nella fase di progettazione i programmatori non sono neanche presenti, bensi' una vasta serie di divisioni molto variegate (tipo ricerca, ingenieria, marketing, finanze, saleforce e cosi' via). Per progetti piccoli, e' come uccidere una mosca con un cannone.
Se siete interessti potremmo parlarne in una discussione separata.

Il senso del mio intervento era un altro, non credo ci sia bisogno di spiegazioni … ;)
Ai miei allievi faccio usare ClickCharts per la modellazione concettuale di un database tramite i diagrammi E-R e UML e non mi pare che sia morta alcuna mosca … :asd:
https://www.nchsoftware.com/chart/index.html :)
--- i due messaggi sono stati uniti ---
Ma, dico io, iniziare a studiare un linguaggio di programmazione (anche semplice inizialmente) tra quelli richiesti attualmente dal mondo del lavoro ? Mi riferisco a Python, R, Java o C#..

Non sono d'accordo con quanto detto da @gronag, almeno per la parte iniziale. Perchè iniziare con un linguaggio che è veramente poco ricercato a differenza di Python e C# ? Capisco il rigore che il Pascal può avere (non lo conosco, ma vado sulla tua parola) però c'è da dire anche che se uno non lo userà tutti i giorni da qui a 2/3 anni (minimo) gli verrà molto difficile padroneggiarlo alla fine.

I tempi sono cambiati e i linguaggi preferiti/richiesti sono altri, tra cui maggiormente, quelli citati sopra. Certo, C e C++ esistono ancora e la richiesta è alta anche lì, ma per iniziare e toccare con mano dei risultati in modo molto rapido io preferirei un Python a C.

My 0,02€...

D'accordo o meno ha poca importanza, ho fatto una proposta all'utente che non sa programmare, dal mio punto di vista più che valida e logica, quella di iniziare dalla programmazione strutturata di Bohm, Wirth e altri ... lasciamo stare il Pascal e Delphi/Objective Pascal, ecc. :sisi:
Non ho mai detto di abbandonare Python (anche se sarebbe il caso di farlo, a mio modo di vedere), del resto si tratta di una materia di studio e come tale va studiata bene :sisi:
Tu cosa proponi in alternativa ? :skept:
--- i due messaggi sono stati uniti ---
Perché parlare di aria fritta?
Qui il punto è un altro: il professore dell'utente che ha aperto la discussione ha deciso per Python, quindi possiamo stare a discutere fiché volete, ma l'utente deve imparare a programmare usando Python come mezzo.

E io non ho mai detto il contrario … quindi ? ;)
 
Ultima modifica da un moderatore:
Assolutamente NO. Quello era vero una volta, quando si parlava in termine di "algoritmi" che era in pratica sinonimo di "algoritmi matematici", utili appunto a risolvere un problema matematico. Si "traduceva" un problema in numeri e vettori capaci di memorizzarli, e si scriveva un algoritmo. Tipo il Bubble Sort.
Adesso le cose sono cambiate parecchio. Usiamo linguaggi di alto livello, non stiamo piu' a reinventare la ruota. Il Bubble Sort lo impariamo a scuola, ma poi quando andiamo a lavorare il nostro manager ci licenzia in tronco se scriviamo un Bubble Sort di nostro pugno, per lo stesso motivo che non scriviamo il nostro compilatore e il nostro sistema operativo.
Ormai chi scrive algoritmi sono ben poche persone, principalmente a livello accademico. Chi lavora deve affrontare un problema reale, deve trovare gli strumenti piu' adatti per risolverlo. Per esempio, progettare e poi ottimizzare le tavole di un database per ottimizzare il tempo di richiesta da parte di un utente.

d'accordissimo con te, io se al mio capo gli chiedessi di scrivere una porzione di programma con un quicksort quello manco sa di cosa sto parlando...
Scherzi a parte il problema dell'utente non riesco a capire se è improntato al fatto che se ha una traccia davanti non capisce che strutture usare per implementarla, oppure se proprio non capisce la logica dell'esercizio richiesto.
Senza dubbio per me dovrebbe in primis rileggere mille o piu volte la traccia dell'esercizio e cercare di capire cosa richiede poi in secondo luogo iniziare a scrivere il codice.
Ma io penso di aver capito che l'utente in questione abbia difficoltà nel capire in primis cosa chiede la traccia e quindi in annesso poi non sa cosa scrivere
 
Pubblicità
Pubblicità
Indietro
Top