Qual è il tuo approccio alla programmazione multi-paradigma?

Question

Qual è il tuo approccio alla programmazione multi-paradigma?

#1 da (11 voti)
#2 da (4 voti)
#3 da (0 voti)

6

Recentemente ho imparato un po 'di Ruby e ho avuto la seguente esperienza. Avevo scritto un piccolo strumento di circa 200 righe di codice e, come programmatore di Ruby inesperto, avevo usato diversi loop per costruire array da altri array. Per es.

gs = ... # Some array of input data.
l  = gs.size
i  = 0
r  = Array.new
while (i < l) do
  if (cond(gs[i]))
    r.push(gs[i])
  end
  i = i + 1
end

# r contains the result now.

Poi ho scoperto che posso farlo in uno stile funzionale:

gs = ... # Some array
r  = gs.select { |g| cond(g) }

# r contains the result now.

Quindi ho sostituito immediatamente la maggior parte dei miei loop nel codice con costrutti come ogni, select, take_while, drop_while e così via. Ho deciso di utilizzare uno stile funzionale in Ruby ogni volta che è possibile e cercare di evitare uno stile imperativo.

Come altro esempio, in C ++ tendo ad usare classi e metodi ovunque e uso le funzioni solo per piccoli compiti di utilità privati per l'implementazione di qualche classe. Quindi tendo a pensare agli oggetti orientati quando lavoro in C ++ ed evito uno stile procedurale quasi completamente.

Più in generale, quando lavoro su un dato progetto in una determinata lingua, tendo a scegliere un paradigma e ad attenervici per tutto il progetto: trovo che questo rende il mio codice più uniforme, più facile da leggere e da debugare, il che, IMO, è molto importante, soprattutto per il codice di produzione.

Tuttavia, spesso penso che forse dovrei esplorare di più e provare diverse possibilità offerte da un linguaggio, ad es. utilizzare diversi paradigmi e provare diverse soluzioni. Per me ciò comporta un sovraccarico sia durante la codifica (dovrei renderlo procedurale o orientato agli oggetti? Imperativo o funzionale?) E durante la revisione o il debug del codice (cosa volevo fare qui?) A causa della maggiore complessità.

Quindi la mia domanda è: tendi anche a selezionare un paradigma di programmazione preferito quando si codifica e ci si attiene, o si tende ad esplorare di più ea mixare diversi paradigmi?

Se mischia paradigmi diversi, hai la sensazione che ci sia un sovraccarico in termini di quanto velocemente puoi scrivere ed eseguire il debug del codice (aggiunta complessità, passaggio tra mentalità diverse) o è solo questione di imparare come fare e allora puoi anche essere più produttivo?

O mescoli diversi paradigmi in un modo più strutturato, ad es. applicate ciascun paradigma a una specifica classe di problemi (ad esempio, funzionale per le query, orientata agli oggetti per gli aspetti architettonici e così via)?

coding-style programming-practices paradigms

posta Giorgio 22.04.2012 - 12:28

fonte

3 risposte

11

Tendo a pensare meno nei "paradigmi" e più in termini di utilizzo dello strumento più appropriato (cioè semplice, leggibile e manutenibile) per il lavoro. Non credo di attenermi rigidamente ai paradigmi perché ritengo che spesso si traduca in un modo per scrivere codice in un certo modo solo per il rispetto delle "regole". Tuttavia è certamente utile imparare molte tecniche diverse per l'utilizzo della lingua scelta (e l'apprendimento di lingue diverse può spesso aprire gli occhi a idee nuove di zecca che forse non avresti considerato prima)

per esempio, un approccio OO "puro" è quello di avvolgere tutto come un oggetto; a volte è appropriato se stai scrivendo un framework pieno di componenti riutilizzabili, ma per un semplice problema specifico, il risultato finale potrebbe essere solo ingombrante, gonfio e complicato.

Allo stesso modo, un approccio di programmazione funzionale "pura" implica condizioni rigorose di valutazione lazy - usando ovunque oggetti di funzione completamente privi di stato - questo è semplicemente impraticabile per il 99% dei problemi, ma lo stile delle funzioni di passaggio può a volte risultare molto soluzioni eleganti e semplici.

in C ++ (la mia lingua principale), ad esempio - trovo che il passaggio di functionoid può aiutare a costruire codice molto pulito quando si tratta di situazioni che potrebbero altrimenti essere risolte passando riferimenti a oggetti ovunque (ad esempio contenitori / algoritmi di librerie standard, e per qualsiasi cosa guidata dagli eventi), ma c'è molto spesso un qualche tipo di stato associato a quei functionoids quindi non si qualifica veramente come "funzionale".

Allo stesso tempo, i modelli C ++ possono essere utilizzati per la programmazione basata sull'interfaccia - i modelli fanno generalmente parte del paradigma di programmazione generico, ma mi trovo a usarli come un modo di gestire Dependency Injection in fase di compilazione (noto anche come "Policy Based "classi), con il risultato di un ibrido generico OO abbastanza facilmente accoppiato che consente un test dell'unità molto semplice.

Tutto varia da una lingua all'altra - Sono pienamente consapevole che i programmatori C # non ottengono la dipendenza dall'iniezione tramite i generici (anche se i generici sono l'equivalente più vicino ai modelli), ma perché C # ha un insieme di regole totalmente diverso - quindi ancora , si riduce allo strumento linguistico più appropriato invece di attenersi a un paradigma. Uno dei motivi per cui molti linguaggi generici sono generalmente etichettati come "multi-paradigma" è il fatto che le persone che usano quelle lingue tendono a evitare l'ideologia e mirano a trovare soluzioni utilizzando un'ampia varietà di strumenti diversi.

risposta data 22.04.2012 - 13:13

fonte

0

Come nel tuo esempio, penso che ogni lingua ti spinga verso un particolare paradigma. Se sei intelligente, scoprirai come la lingua ti vuole per risolvere il problema e lo fai in questo modo o abbandoni la lingua. Suppongo che alcune lingue siano un po 'più neutrali. Ho trovato che C poteva essere piegato in qualsiasi direzione, ma era molto lavoro. Se mi fossi fermato un paio di anni fa, avrei scritto il mio garbage collector per questo.

Attualmente, ho diviso il mio tempo tra C # e Java. Per esempio, un programmatore C ++, queste due lingue devono apparire quasi identiche, ma trovo che scrivo in modo molto diverso in ciascuna di esse. Ho difficoltà a dire perché.

La maggior parte delle lingue, tuttavia, presenta differenze ovvie - nel tipo di dati che sono destinati a gestire - nel loro compromesso tra prestazioni, facilità di programmazione, esigenze hardware, ecc. Quindi le loro differenze di paradigma sono ovvie e comprensibili - e anche prevedibile.

risposta data 23.04.2012 - 16:28

fonte

Leggi altre domande sui tag coding-style programming-practices paradigms

perché entrambi indice [array] e array [indice] sono validi in C? Denominazione del metodo di classe derivata

score 4 · Accepted Answer

do you also tend to select a preferred programming paradigm when coding and stick to it, or do you tend to explore more and mix different paradigms?

L'esplorazione costante di soluzioni alternative ti rende un programmatore migliore. Devi essere consapevole degli strumenti disponibili, non significa che devi usarli ogni volta.
Il mix dei paradigmi va bene finché non ha un impatto negativo sulla qualità del tuo codice.

If you mix different paradigms, do you have the feeling that there is some overhead in terms of how fast you can write and debug code (added complexity, switching between different mindsets) or is it just a matter of learning how to do it and then you can even be more productive?

Se questo è il tuo progetto e nessun altro lavorerà su di esso, allora è assolutamente bene. Potrebbe costarti più tardi, ma la cosa buona è che non influenzerà nessun altro.
In generale, penso che i team cercheranno di non utilizzare il multi-paradigma poiché è probabile che abbiano un impatto negativo sulla produttività del team. D'altra parte, sperimentare, come passare da un paradigma all'altro, è un ottimo modo per imparare.

Or do you mix different paradigms in a more structured way, e.g. you apply each paradigm to a specific class of problems (e.g. functional for queries, object-oriented for architectural aspects, and so on)?

Indipendentemente da ciò che fai, devi pianificarlo e pensare a quale effetto potrebbe avere in futuro. Pertanto, sì, qualunque cosa tu decida di fare, deve essere strutturata e pianificata per.
Il mio team ha concordato linee guida sul codice e abbiamo sempre utilizzato queste linee guida con spostamenti di paradigma molto piccoli o addirittura nessuno. Disponiamo anche di strumenti che rafforzano queste linee guida. Nel tuo specifico esempio, ReSharper ci suggerirebbe di convertire un'istruzione foreach in una istruzione LINQ più leggibile.

Per riassumere, penso che esplorare i cambiamenti di paradigma sia un ottimo modo per imparare, ma dovrebbe essere rigorosamente controllato in un ambiente di lavoro.