Quale paradigma del linguaggio di programmazione si adatta a quale lavoro?

Question

Per quanto ne so (non lo ammetterò), i paradigmi di programmazione attualmente popolari sono Object Oriented (Java, C #, Ruby) vs funzionali (F #). Come persona che ha familiarità con il primo paradigma, ho diverse domande:

• Un programmatore può semplicemente attenersi a un paradigma per tutta la sua vita? O in altre parole, tutti i problemi possono essere ridotti a chiodi per un martello?
• In caso contrario, quale strumento è adatto a quale tipo di attività? Ad esempio: web-based vs desktop, creando interfacce belle e reattive, in grado di sgretolare rapidamente i dati, ecc.
• Le persone hanno mai avuto bisogno di imparare un nuovo paradigma? Per i miei due precedenti lavori, i miei posti di lavoro richiedevano Java e C #. Esistono ambienti di lavoro che utilizzano specificamente lingue non OO?

Ovviamente non ci sono " migliori " lingue, ma mi chiedo se valga la pena investire tempo ed energia per imparare un nuovo paradigma. Grazie in anticipo!

Answer 1

" O in altre parole, tutti i problemi possono essere ridotti a chiodi per un martello? " Sì. Periodo. Qualsiasi linguaggio di programmazione che probabilmente incontrerai sarà completo come tutti gli altri. In realtà esiste una definizione formale di "completezza" per un linguaggio di programmazione.

" Le persone hanno mai avuto bisogno di imparare un nuovo paradigma? " Sempre.

In realtà c'è un trucco nel seguire gli alti e bassi dei "cambi di paradigma". Negli ultimi 30 anni della mia carriera, ho visto che la programmazione è passata da un modello imperativo / procedurale relativamente semplicistico a un numero di modelli molto più ricchi che includono un migliore equilibrio tra processo e dati.

Ho notato quanto segue ...

Parte della forza trainante è la comunità dell'intelligenza artificiale. Molti di questi "nuovi modelli" iniziato come schemi di rappresentazione della conoscenza AI. Hanno ottenuto trazione lì, poi sono entrati in altre applicazioni mainstream.

Il modello di Entity Relationship era originariamente per la rappresentazione della conoscenza, non per le transazioni commerciali. Il modello Object, allo stesso modo, era per la rappresentazione della conoscenza. Quindi la gente di simulazione l'ha trovata. Ora tutti noi ce l'abbiamo.

Ecco la mia conclusione.

Il software è rappresentazione della conoscenza.

La scelta del paradigma o modello o approccio o stile si basa sulla risposta alla seguente domanda:

" Come posso rappresentare al meglio questo problema? "

Se il problema ha oggetti e relazioni, OO. Se il problema presenta algoritmi e trasformazioni, mappe, filtri e riduzioni, Funzionale. Se il problema è dinamico, mutevole e flessibile, dinamico. Se il problema è statico e si espanderà rapidamente, Statico.

Answer 2

Vale la pena imparare paradigmi alternativi (OO, funzionali, procedurali, dinamici, ecc.) perché ti aiuteranno a pensare ai problemi in diversi modi.

Ad esempio, pensa alla differenza nel risolvere un attraversamento di alberi in modo lineare (il primo modo in cui l'ho mai fatto) rispetto all'utilizzo della ricorsione. O la combinazione di Google di Map and Reduce per aiutarli a indicizzare Internet.

Nuovi modi di pensare applicati a vecchi problemi possono aiutare a risolvere alcuni dei problemi più difficili.

Answer 3

Il paradigma è indipendente da una lingua. Puoi sviluppare in stile OO in C (dai un'occhiata a GTK). Quando programma in Java, utilizzo principalmente lo stile funzionale.

Vale la pena conoscere il maggior numero possibile di paradigmi. Alcuni problemi sono banali da risolvere in un paradigma e richiedono una delicata lavorazione in un altro.

Come esempio (banale), confronta le implementazioni di quicksort in Java e Ocaml, o meglio, Haskell, in questa pagina: http://www.rosettacode.org/rosettacode/w/index.php?title=Quicksort

(Ciò non significa che il funzionamento sia migliore. Ci sono problemi meglio risolti con OO).

Answer 4

  

Tutti i problemi possono essere ridotti a chiodi per un martello?

Err sì. Puoi risolvere i problemi con un solo martello. Sta solo vedendo quella porta a metà impiega molto più tempo con essa.

  

Le persone hanno mai avuto bisogno di imparare un nuovo paradigma? Per i miei due precedenti lavori, i miei posti di lavoro richiedevano Java e C #. Esistono ambienti di lavoro che utilizzano specificamente lingue non OO?

Gli sviluppatori devono farlo ogni 15-20 anni circa.

Esiste sicuramente un intero settore di piccole aziende con sistemi basati su Access scritti con VBA procedurale. (e penso di aver lavorato per la maggior parte di loro). Gli sviluppatori ASP classici devono imparare ASP.NET. Gli sviluppatori Perl stanno imparando Python. Lo sviluppo guidato da lotti ha lasciato il posto allo sviluppo guidato da eventi.

Answer 5

Penso che troverai risposte su tutta la linea. Più lavoro, più trovo che sia " utile " per conoscere alcuni degli altri. come sviluppatore di C # / VB / SQL trovo più utile per me imparare un po 'su F # e alcune delle altre lingue là fuori per ottenere una vasta esposizione, per capire davvero quale strumento è il giusto ...

Answer 6

Le cose dinamiche mi spaventano a morte, ma Ruby on Rails è di gran lunga il miglior sistema di sviluppo che abbia mai visto per le cose sul web. Non mi sento a mio agio nell'usarlo per un progetto di manutenzione molto grande e pesante, perché è troppo facile alterare il significato del codice esistente, compilato e finito. Anche troppo facile per lo stile di codifica di una persona per renderlo in una nuova lingua.

Dinamico / scripting è anche utile per gli amministratori di sistema e per chiunque esegua un sistema Linux. Scrivere uno script veloce in BASH o Ruby batte l'inferno nel tentativo di implementare la stessa funzionalità in Java o C ++.

OO rende molto più semplice la comprensione di grandi quantità di codice. Se disponi di un team di grandi dimensioni o di più team di grandi dimensioni e devi fornire rapidamente una panoramica, OO semplifica notevolmente la descrizione e l'isolamento di una determinata funzionalità. Dovrei dire OO CORRETTAMENTE CODIFICATO!

Comprendo che il funzionamento funzionale è utile per la programmazione multi-thread poiché tutto tende a essere immutabile.

Answer 7

Sviluppare le capacità progettuali e di architettura tenendo presente OOP è lo skillset più desiderabile per una carriera agnostica di grande linguaggio.

Il vantaggio quando si codifica in Oops è sia per gli altri membri del team là fuori che per l'organizzazione nel suo insieme. Poiché il codice sarà comprensibile a tutti e se gli sviluppatori lasciano il lavoro, l'azienda non deve preoccuparsi molto. Nell'altro caso, se segui lo stile funzionale, sarà molto difficile per gli altri capire cosa hai fatto.

Answer 8

Come molti altri hanno già detto, puoi generalmente usare qualsiasi linguaggio per risolvere qualsiasi problema e di solito puoi scrivere nello stile di un paradigma in un altro.

Se prendi il tempo per imparare ad usare i diversi paradigmi come sono previsti, allora impari cose diverse sulla rappresentazione della conoscenza e sulla risoluzione dei problemi che possono essere utili in qualsiasi paradigma che stai usando in futuro.

Sebbene vi sia un certo allineamento tra paradigmi e domini, in genere è meglio scegliere una lingua in base alle specifiche dell'ambiente in cui il software deve operare.

• Deve essere eseguito su più piattaforme desktop?
• Se si tratta di un'applicazione desktop, deve avere un aspetto nativo?
• È importante una rapida iterazione dei disegni
• Come deve essere mantenuto?
• Con quali sistemi di terze parti deve funzionare?
• Conoscenze / abilità / preferenze del programmatore esistenti.