Quali linguaggi di programmazione dovrebbe essere insegnato a ogni studente di informatica?

Quali lingue (o classi (come nei paradigmi) dei linguaggi di programmazione, oltre a una lingua raccomandata di quella classe), ogni studente di informatica dovrebbe essere insegnato al college secondo te? Motiva le tue risposte; perché quella lingua? Che uso ne trarrà? Quali concetti insegna (meglio della lingua X)?

Nota / chiarimento : questa domanda riguarda l'informatica con particolare attenzione all'ingegneria del software, non all'informatica pura. Al centro è ancora l'educazione informatica e non l'educazione all'ingegneria del software.

Ho intenzione di dare un elenco:

• Assemblea (un dialetto relativamente semplice): è importante capire almeno un po ' dei fondamenti
• C: linguaggio procedurale, usato in molti luoghi. Non carica nuovi studenti con concetti completamente nuovi come OOD tutti in una volta.
• Java / C # / Eiffel / C ++: Qualcosa orientato agli oggetti è buono, ognuno di questi raggiungerebbe l'obiettivo di insegnare agli studenti OOD e una volta che capiscono una di queste lingue, dovrebbero essere in grado di imparare le altre .. Ci sono molti buone lingue, ho elencato Eiffel perché ha anche un design per contratto.
• LISP e Prolog: insegna agli studenti un modo completamente nuovo di pensare, che è importante, anche se non usano mai nessuno di questi "nel mondo reale".
• SQL e XML: introduce nuovi modi di pensare ai dati e come recuperarli e gestirli.

Gli studenti dovrebbero essere esposti a tutti questi paradigmi almeno. Non solo uno o due.

Suppongo che molte persone suggeriranno a Python di coprire lo stile procedurale, lo stile OOP e forse altri, ma non ho abbastanza esperienza personale con Python per poterlo consigliare con sicurezza.

Personalmente trovo un po 'triste che le lingue funzionali non vengano insegnate in modo predominante come una volta. Penso che almeno gli studenti di scienze della scienza dovrebbero essere esposti a un linguaggio di tutti i principali paradigmi: procedurale, orientato agli oggetti, funzionale e dinamico.

Penso che a uno studente CS ben bilanciato dovrebbe essere insegnata una lingua in ciascuno dei 4 tipi di linguaggio di programmazione:

Funzionale - Lisp / Haskell / PostScript. Non ho molta esperienza con Haskell, ma ho sentito altri programmatori che ne sono entusiasti. Comprendere i costrutti della programmazione funzionale e perché sono utili in molte situazioni aiuterà un programmatore a diventare migliore nell'organizzazione di algoritmi anche in altre lingue.

Orientato agli oggetti : fai la tua scelta. C # / Java / Python / Ruby / yadda yadda yadda. Questo tipo deve essere insegnato semplicemente perché è quello che vogliono le aziende moderne.

Imperativo - C / Fortran / Pascal. Questi sono meno comuni in questi giorni, ma dovrebbero comunque essere appresi da una prospettiva pratica / storica. I metodi che impiegano hanno ancora praticità perché in ogni lingua tutto si riduce a un'istruzione. E le lingue imperative sono molto brave a elencare e seguire le istruzioni.

Logico - ProLog. Non ho mai trovato un buon uso pratico per nessuno di questi linguaggi, ma ho trovato utili alcuni dei concetti alla base dei linguaggi logici quando ho cercato di capire come scrivere alcuni dei miei metodi in linguaggi più orientati agli oggetti. Non sono riuscito a concentrarmi a lungo sui linguaggi logici durante gli anni del college, e penso che una maggiore attenzione lì avrebbe potuto farmi del bene allora.

La lingua numero 1 che ogni laureato in medicina specialistica dovrebbe conoscere è quella che massimizza il loro potenziale per ottenere un ottimo lavoro. Questo cambierà nel tempo, cambierà in base alla definizione individuale di ottimo lavoro e varierà in base alla regione geografica.

Per il momento, dirò che l' inglese è la lingua numero 1 che tutti i maggiori CS dovrebbero sapere (questo, ovviamente, varia in base alla regione).

Penso che cambi con il tempo, ma idealmente - 3 lingue da 3 prospettive molto diverse. Ai miei tempi era procedurale, OO e funzionale - Pascal, C ++ e LISP. Non sono così venduto su quei tre in particolare. Ma quando intervisto cerco:

• Un certo livello di esperienza con un linguaggio in cui devi prestare attenzione alla gestione della memoria (C / C ++ e molti altri)
• Qualche livello di esperienza con un linguaggio orientato agli oggetti con aspettative sull'uso delle API e le varie astrazioni disponibili (C ++ / Java)
• Un linguaggio "allungato" - qualcosa di strano, difficile e stimolante. Non ho intenzione di assumere perché qualcuno conosce LISP, assembly o qualche altro linguaggio impegnativo, ma voglio vedere che l'ingegnere ha affrontato una sorta di sfida che comportava seri problemi e un sacco di "che diamine è questo?" momenti.

Come un altro commercio - penso che i programmi CS debbano formare gli studenti su lingue di spicco sul mercato. In qualsiasi momento, penso che 2-3 lingue abbiano una seria importanza per la maggior parte dei lavori. Penso che una scuola debba agli studenti l'opportunità di imparare 2 su 3 di quella lingua con una profondità di formazione disponibile in almeno una.

Per uno studente CS, cerca linguaggi di programmazione strettamente associati ai concetti CS discussi. Suggerirei:

• Schema, per comprendere meglio il calcolo lambda
• Erlang, per capire il modello dell'attore
• Prolog, per logica predicata e sistemi di prova
• Haskell, per la teoria del tipo / categoria e perché la valutazione pigra è così pienamente espressa nella lingua
• almeno un linguaggio assembly - se si desidera contarlo sotto questo banner, aggiungerei anche un linguaggio di codice byte, come i codici byte Java o CLR, e l'IR LLVM
• probabilmente un linguaggio di definizione hardware, come Verilog o VHDL
• Bisonte per una classe di costruzione di compilatori
• qualcosa con un sistema di tipo dinamico (mi viene in mente Ruby) ...

L'elenco potrebbe continuare in questo modo, ma l'idea fondamentale è piuttosto semplice: insegnare agli studenti il ​​linguaggio di programmazione che sarà più adatto al modo in cui si desidera insegnare i concetti.

yacc

per avere un'idea di cosa sta succedendo dietro le quinte, qualunque sia il linguaggio di programmazione che stai usando. aiuta a comprendere concetti di base come il codice morto e vari tipi di ottimizzazioni che un (buon) compilatore sarà in grado di fare per te.

Lisp (con CLOS per OOP) e Haskell. Questa domanda non è limitata agli studenti. Nuovi linguaggi di programmazione fantasiosi hanno preso in prestito (copiato, rubato? ... no, non è male) molte funzionalità di questi due. Puoi prepararti per il futuro. La programmazione funzionale (stile) è oggi più importante ed è introdotta in linguaggi di programmazione imperativa come C # (LINQ) o C ++ (lambda) e molti altri. È un peccato che alcuni studenti imparino solo Java.

Penso che la lingua non sia così importante come la gente crede.

Sì, devi sapere come programmare ecc., Ma molti grandi programmatori sono autodidatti attingendo alle loro esperienze del mondo reale che li aiutano durante lo sviluppo.

Gli studenti potrebbero fare alcune lezioni su come programmare nel mondo reale e non solo sui metodi del libro, questo li renderebbe più "arrotondati" e, a mia discrezione, migliori sviluppatori / laureati.

Ho imparato di più sulla programmazione e sullo sviluppo del software dopo che ho lasciato l'università e ho iniziato a lavorare!

IMPORTA DAVVERO ?

Di solito il prurito dietro questa domanda è "Quali parole d'ordine posso mettere sul mio curriculum che mi farà ottenere i lavori più redditizi / interessanti / stimolanti / facili?". Sebbene la domanda abbia dei meriti, dato che la maggior parte dei curricula viene prima vagliata dalle persone che non capiscono cosa stanno cercando. ma è molto superficiale, poiché una volta superate le porte è necessario consegnare la merce.

Non sono le lingue che conosci che ti rendono un programmatore buono o cattivo, è come puoi usarlo. Per questo ci sono fondamentalmente due categorie di programmatori:

1. Quelli che si concentrano sull'apprendimento di una lingua al suo interno. La più importante è la lingua e come usarla. All'estremo, tendono a ottimizzare al massimo ogni piccolo granello di codice e spesso usano funzionalità oscure solo perché possono.

2. Poi ci sono quelli che vogliono conoscere tecniche e paradigmi. La lingua che usano non ha molta importanza finché può esprimere elegantemente la loro immagine mentale. In casi estremi questi tenderanno a usare UML o altri sistemi simili sperando che altri facciano il duro lavoro di codificarlo.

Secondo me hai bisogno di entrambi. Il n. 1 fornirà competenze a breve termine e, se saggiamente scelto, ti faciliterà attraverso le porte delle risorse umane, ma il n. 2 rimarrà con te per tutta la tua carriera e ti definirà un programmatore.

# 2 fornirà una guida e organizzerà il tuo treno di pensieri verso una soluzione funzionante al problema in questione, ma senza 1 rimane un'idea, che galleggia per sempre negli arti del cielo di vaporware (o inferno a seconda di dove lo guardi).

# 1 ti darà i mezzi per implementare le idee in sistemi di lavoro reali ma senza 2 i tuoi sistemi tenderanno verso mostri informi cancerosi.

Credo che tu abbia parzialmente risposto alla tua domanda da solo.

Di reale importanza è dare agli studenti l'opportunità di entrare in contatto con diversi paradigmi, le lingue attuali non dovrebbero importare.

Naturalmente, è importante insegnare principalmente quei paradigmi che offrono la maggior parte delle opportunità di lavoro (probabilmente OOP in questo momento). Di conseguenza, è anche meglio insegnare una lingua ampiamente usata per questo paradigma, poiché è più utile che imparare qualcosa che probabilmente non userete mai. Quindi odiavo anche dover scrivere pseudo codice sui miei esami. Lo pseudocodice va bene, purché non abbia una sintassi "fissa". Dovresti solo essere in grado di far conoscere i concetti.

Quindi concretamente:

OOP: .NET o Java

Almeno 1 paradigma di programmazione aggiuntivo, per rendere lo studente consapevole di altri approcci.

Funzionale: Lisp?

Linguaggio di assemblaggio e microcodice. Uno studente CS dovrebbe comprendere tutti gli strati di base dell'astrazione tra macchine a stato booleano e l'ultimo funzionale di alto livello / OOP / ecc. paradigma del linguaggio di programmazione.

Basic o Logo o Squeak (et.al.), se mai vogliono essere in grado di capire come insegnare ai bambini piccoli un po 'di alfabetizzazione informatica.

Fortran, Cobol e Lisp, se vogliono capire la storia dei linguaggi di programmazione e quali sono i problemi reali risolti dalle pratiche moderne.

Scegliere 3 o più lingue da paradigmi diversi non è poi così difficile, sono state fornite molte buone risposte. Ma se dovessi scegliere solo una lingua, sceglierei Scala, perché è sia funzionale che orientato agli oggetti. Puoi spiegare e confrontare diversi approcci nella stessa lingua.

Non dimenticare i linguaggi concatenativi / orientati allo stack! Possono essere dei veri sbalorditivi. Sottolineano la complessità della costruzione usando primitivi piccoli e di facile comprensione. Puoi usarli per scrivere un codice privo di punti (o tacito) che sembra così dannatamente pulito.

Il linguaggio classico è Forth , ma il mio go-to in questi giorni è Factor . Vale anche la pena dare un'occhiata a Joy e Cat . Non perdere il wiki del linguaggio concatenativo . È più divertente di una borsa piena di martelli!

Qualcosa di funzionale, Haskell o Lisp sarebbe la mia prima scelta, ma forse Erlang. I linguaggi funzionali ti insegnano davvero come costruire le astrazioni in un modo molto potente.

Nonostante la sua mancanza di mainstreaming, trovo che D, in particolare la versione 2, fornisca alcune interessanti lezioni che non possono essere facilmente apprese altrove. Fa un tentativo più serio di qualsiasi altro linguaggio che mi viene in mente di ottenere una programmazione imperativa / procedurale, orientata agli oggetti e funzionale per giocare bene l'uno con l'altro e consentire la programmazione a un livello molto basso (puntatori, gestione manuale della memoria, in linea assembly assembly) e un livello molto alto (programmazione generica e generativa) nella stessa lingua.

Ciò è prezioso perché, anziché vedere i paradigmi isolati come se esistessero in universi diversi, si arriva a vedere la foresta attraverso gli alberi. Puoi vedere i punti di forza e di debolezza di ogni paradigma a un livello ben preciso mentre li fondi nei tuoi programmi. Puoi vedere come i principali aspetti dei paradigmi possono essere implementati nelle biblioteche in termini di codice di livello inferiore. Il modulo standard della libreria std.algorithm implementa importanti primitive di programmazione funzionale, ma è un codice D semplice e diretto senza magia. Allo stesso modo, std.rangeimplementa una valutazione pigra, ma ancora una volta è un codice D abbastanza semplice. Comprendi i costi delle primitive di ogni paradigma, perché le caratteristiche vicine al metallo di D rendono relativamente trasparente ciò che sta realmente accadendo sotto il cofano. Puoi anche scrivere qualcosa di basso livello che assomigli a C, e quindi creare un'interfaccia carina e di alto livello, nella stessa lingua, senza che vi siano strati di colla magica che si frappongono.

Pseudocodice.

Le persone sul campo dovrebbero essere in grado di spiegare le proprie idee in modo coerente e strutturato senza un gergo specifico per la struttura o la sintassi. Non dovrei conoscere la differenza tra parentesi quadre e parentesi graffe per capire il tuo algoritmo. Non dovrei aver bisogno di sapere cosa ??significa o quali sono gli grepinterruttori.

Scrivi in ​​un linguaggio semplice, ma strutturalo e formattalo come un codice. Chiunque può quindi implementarlo nella lingua che preferisce.

modifica: questa risposta è in parte motivata dall'incapacità di alcuni programmatori di scrivere pseudocodici.

"Basta scrivere l'algoritmo in pseudocodice"

"Cos'è quello?"

I vantaggi dello pseudocodice è che le parti interessate non programmatrici possono comprenderlo. Non sto suggerendo che desideri che BA e utenti eseguano la correzione del codice, tuttavia può essere utile quando un non programmatore ha una comprensione dell'algoritmo richiesto. Psuedocode elimina la necessità di spiegare for (int i = 0; i < j; i++)e ciò che è essenzialmente gergo di fanteria.

C.

• Prima di tutto, è ancora usato (ampiamente usato!), E non solo per i kernel. Attualmente sto gestendo un'applicazione aziendale codificata in C. Quindi, anche con C pura e semplice, puoi ancora ottenere un lavoro. Nelle grandi aziende, nell'industria, quasi ovunque (ma nel web dev).
• Se hai intenzione di lavorare in un ambiente Unix / Linux, non conoscere almeno un po 'di C è un po' come fare shopping e non essere in grado di leggere i prezzi sui tag.
• Puntatori! Tutti dovrebbero capire i puntatori (cfr. Joel Spolsky ). Inoltre, una volta afferrato il concetto malloc, sai esattamente che tipo di cose accadono quando digiti con noncuranza un "nuovo" in una lingua OOP.
• La maggior parte delle sintassi di "lingue popolari" deriva da C.
• Sì, non è sempre chiaro. Sì, è difficile da imparare. Sì, le stringhe sono un po 'un incubo per i principianti. Ma la programmazione non è sempre chiara ed è difficile da imparare, e capirai davvero cosa c'è di grande in OOP quando, dopo aver studiato C, provi C ++ e scopri std :: string.

Naturalmente, si dovrebbe conoscere più di una lingua e non solo un vecchio linguaggio procedurale. Ma se dovessi andare su un'isola deserta con un solo compilatore, andrei con il mio buon vecchio gcc. È possibile comprendere la programmazione di alto livello se si conosce la programmazione di basso livello. Penso che non sia vero il contrario.

Alcuni dei linguaggi di programmazione applicati per acquisire capacità generali di problem solving, e concetti di programmazione sono Logo e Karel, dovrebbero essere insegnati prima di C / C ++ / Java / Lisp / PERL / Assembly / qualunque sia il paradigma di programmazione.

Gli studenti ottengono un'introduzione molto pratica alla programmazione.

Qualsiasi cosa con oggetti. Assicurati solo che lo imparino bene.

Assumerei un grande programmatore Java per C # in qualsiasi momento, ma avrei molti dubbi nell'assumere qualcuno che non ha mai scritto codice reale