Costruisci la tua logica di soluzione in sintassi o in un modello mentale più veloce ed efficiente?

Il modo in cui un programmatore pensa a un problema (e una soluzione) dipende notevolmente da come pensano le cose in generale, il problema stesso e il loro livello di esperienza in particolare. Vediamoli in ordine:

In che modo le persone pensano in generale

Diverse persone imparano e pensano in modo diverso. Personalmente, sono un pensatore estremamente visivo e tendo ad usare molta intuizione su come le cose "si adattano". Questo è letteralmente perché ho un modello mentale per diversi modelli, moduli e dipendenze all'interno del codice. Quando non riesco a sistemarli in una buona forma, so che la soluzione non è adeguata.

Gli altri sono molto logici, hanno serie di fatti che sembrano ridurre in un risultato. Eppure altri sono legati a un tipo di apprendimento verbale o uditivo. Hanno bisogno di sentire un problema descritto per capire le relazioni e sottolineare di esso. E, naturalmente, nessuno è "solo" visivo o "solo" verbale. Si mischiano e si abbinano a diversi livelli.

Il problema stesso

Diversi problemi richiedono soluzioni diverse. Quando sto progettando un'architettura per gestire migliaia di transazioni al secondo, ci penso diversamente da come provo a creare un algoritmo di pianificazione. Hanno esigenze diverse e l'utilizzo di approcci diversi per la risoluzione dei problemi mi consente di essere più efficace rispetto all'utilizzo dello stesso approccio per tutto.

Il livello di esperienza del programmatore

Quando i principianti iniziano, conoscono la sintassi e (se sono fortunati) hanno una buona conoscenza del concetto di variabili. Quando vengono presentati con un problema di programmazione, lo affronteranno con questi concetti, perché è quello che sanno.

Man mano che acquisiscono esperienza ( specialmente con linguaggi / paradigmi diversi ) iniziano a astrarre la concreta sintassi in concetti. Invece di pensare "oh fai una classe che eredita da XYZ" loro possono pensare "ho bisogno di qualche sorta di polimorfismo qui". I Pattern di progettazione (se usati bene) sono il tipo di cosa che estende ulteriormente questo in modo che il programmatore possa pensare a strumenti che comprendono più ampi andamenti di sintassi.

Questa è la ragione principale per cui "apprendere una varietà di paradigmi del linguaggio di programmazione" è un suggerimento comune nello sviluppo dei programmatori. È anche il motivo per cui il C ++ ha perso molto favore come primo linguaggio di programmazione (in alcuni ambienti): passi troppo tempo a pensare alla sintassi e non a imparare come risolvere i problemi.

( tl; dr ) In generale, per la maggior parte dei problemi, i programmatori passano dal pensare in sintassi al pensare nel proprio modello mentale mentre acquisiscono più esperienza.

La tua affermazione secondo cui a volte pensi al "numero di cicli o condizioni da utilizzare" è in realtà un punto di discussione particolarmente valido.

Osserva questo codice qui dove devi pensare esplicitamente al numero di cicli e alla condizione:

for(i=0; i<data.size(); ++i) { action_func(data[i]); }

e questo codice qui - che raggiunge lo stesso risultato - dove non lo fai:

std::foreach(data.begin(), data.end(), action_func);

La mia interpretazione di ciò che è un modello mentale di programmazione efficiente / più veloce è che qualcuno che ne ha uno, non aggiunge complessità quando non è necessario e vede giusto il problema centrale e non quelli periferici. Questo è importante perché la programmazione riguarda il vedere gli strati di astrazione dal livello più alto a quello più basso - si tratta di lavorare verticalmente in uno stack attraverso questi livelli - non complicando le cose orizzontalmente. Questo è l'unico modo per ottenere la scrittura del codice dell'applicazione che funziona effettivamente in tempi ragionevoli. L'abbellimento all'interno di uno strato viene dopo. Pensa Agile: passa da A a B (ad esempio la GUI del client al database sul lato server) il più rapidamente possibile.

Quindi nell'esempio sopra, non c'è bisogno di parlare di loop o condizioni - non è ciò che si sta cercando di ottenere, quindi non ti preoccupare e usi i costrutti di programmazione al tuo comando per evitare quel problema ( e un'intera classe di bug associati ad esso). Forse più tardi, se action_func diventa qualcosa di più complesso potresti aver bisogno di contare esplicitamente il ciclo. La programmazione riguarda l'espressione di ciò che si vuole fare nel modo più conciso. In molti modi non ti interessa la sintassi - il compilatore / interprete ti aiuterà a farlo bene. Ti preoccupi di più dell'esattezza concettuale di ciò che stai cercando di fare (quindi semplicemente cerchi SE come scriverlo con la sintassi corretta:)

Per quanto riguarda la domanda - cosa imparare? Il mio consiglio è di apprendere le tecniche di programmazione funzionale / imparare un linguaggio funzionale in cui vi è una netta separazione tra l'algoritmo e gli effetti secondari e la maggior parte dei concetti che imparerai avrà un chilometraggio in tutti i linguaggi di programmazione tradizionali.

Continua a programmare. Con una pratica abbastanza ampia, noterai un giorno (potrebbe essere un anno da adesso), che sei alla nuova altezza e puoi "programmare tutto".

Difficile dire dei programmatori in generale, ma non penso che sia "pensare in sintassi". Uno si traduce semplicemente in sintassi, che di solito diventa una habbit. Ecco perché i linguaggi dinamici ed espressivi come Python sono così popolari: consentono di scrivere alla velocità del pensiero.

Quindi sì, con la pratica arriverete a un modello mentale più veloce, che, con ancora più prurito, comprenderà anche più entità alla volta.

Non dimenticare di leggere alcune teorie sulle strutture dati e sugli algoritmi, perché, sebbene non sia fondamentale per acquisire competenze di programmazione, aggiunge diversità al tuo pensiero.

La sintassi è ciò che trasmette la semantica. E il programmatore si occupa della semantica della soluzione, la sintassi è un mezzo per dire semantica al compilatore / interprete del computer.

Potrebbe essere necessario conteggiare il numero di cicli se si utilizzano troppi cicli annidati. Ma la complessità di analisi di un algoritmo è una sua teoria.

Inoltre, IMHO, la programmazione è un'abilità come andare in bicicletta: una volta appreso (noterai il salto al nuovo livello!), è lì con te. Vi sono diversi paradigmi e approcci (imperativo, funzionale, logico, lo nominate), ma l'abilità di base li abbraccia bene e non è dissimile dal nucleo del pensiero matematico, cioè capacità di formalizzare e operare con simboli.