Perché alla domanda "dai cinque cose che odi di C #" è così difficile rispondere durante un'intervista? [chiuso]

Nel podcast 73 , Joel Spolsky e Jeff Atwood discutono, tra gli altri argomenti, "cinque cose che tutti dovrebbero odiare del loro linguaggio di programmazione preferito":

Se sei soddisfatto della tua attuale catena di utensili, non c'è motivo di cambiare. Tuttavia, se non puoi elencare cinque cose che odi del tuo linguaggio di programmazione preferito, allora sostengo che non lo sai ancora abbastanza bene da giudicare. È bene essere consapevoli delle alternative e avere un sano occhio critico per qualunque cosa tu stia usando.

Essendo curioso, ho posto questa domanda a tutti i candidati che ho intervistato. Nessuno di loro è stato in grado di citare almeno una cosa che odiano di C # ¹.

Perché? Cosa c'è di così difficile in questa domanda? È a causa del contesto stressante del colloquio che è impossibile rispondere a questa domanda da parte degli intervistati?

C'è qualcosa in questa domanda che lo rende negativo per un'intervista?

Ovviamente, ciò non significa che C # sia perfetto. Ho un elenco di cinque cose che odio di C #:

• La mancanza di un numero variabile di tipi in generici (simile a paramsper argomenti).
  Action<T>,
  Action<T1, T2>,
  Action<T1, T2, T3>,
        ⁞ serio ?!
  Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>
  

• La mancanza di supporto per le unità di misura, come in F #.

• La mancanza di proprietà di sola lettura. Scrivere un private readonlycampo di supporto ogni volta che voglio una proprietà di sola lettura è noioso.

• La mancanza di proprietà con valori predefiniti. E sì, so che posso inizializzarli nel costruttore senza parametri e chiamarlo da tutti gli altri costruttori. Ma non voglio.

• Eredità multipla. Sì, provoca confusione e non è necessario nella maggior parte dei casi. È ancora utile in alcuni casi (molto rari) e la confusione si applica anche (ed è stata risolta in C #) alla classe che eredita diverse interfacce che contengono metodi con lo stesso nome.

Sono abbastanza sicuro che questo elenco sia lungi dall'essere completo, e ci sono molti più punti da evidenziare, e soprattutto molto migliori dei miei.

^{¹ Alcune persone hanno criticato alcuni assembly in .NET Framework o la mancanza di alcune librerie nel framework o criticato il CLR. Ciò non conta, poiché la domanda riguardava il linguaggio stesso e mentre potevo potenzialmente accettare una risposta su qualcosa di negativo nel nucleo di .NET Framework (ad esempio qualcosa come il fatto che non esiste un'interfaccia comune per TryParse, quindi se vuoi analizzare una stringa in più tipi, devi ripetere te stesso per ogni tipo), una risposta su JSON o WCF è completamente fuori tema.}

Se dovessi indovinare:

1. Alcuni programmatori non hanno un'esposizione linguistica diversa. È difficile vedere le cose sbagliate con la lingua quando non sai che esistono cose migliori.

2. Alcuni programmatori sono semplici scimmie di codice. Analizzano a malapena i problemi che hanno di fronte, per non parlare di qualcosa come il loro linguaggio di programmazione potrebbe essere migliore.

3. Poche persone sono particolarmente critiche. Vedono vantaggi e funzionalità, non carenze. È difficile per loro passare a quel modo di pensare se l'intervista non sta andando in quel modo.

4. Almeno qui, essere eccessivamente critici è visto come un difetto fatale della personalità. Invece di essere "quello sviluppatore perspicace che è sempre alla ricerca di modi migliori di fare le cose" (come alcune aree in cui ho vissuto), sono "quel coglione che odia tutto". Anche le persone che riescono a pensare a cose che odiano nella lingua potrebbero differire in un contesto di intervista per sembrare meno acerbo.

Immagino che alla domanda sia così difficile rispondere durante un'intervista perché è:

1. Davvero inaspettato,

2. Richiede molto pensiero e un pensiero in un modo molto diverso da quello usato durante un'intervista,

3. È difficile rispondere in generale in breve tempo (a meno che non sia preparato prima dell'intervista).

1. È inaspettato

Le domande inattese sono davvero difficili, soprattutto in un contesto stressante. Immagina la seguente finestra di dialogo durante un'intervista:

- Qual è la differenza tra HashSet<T>e List<T>?
- L'hashset è ottimizzato in modo tale che la ricerca di un elemento sia molto rapida. Ad esempio, se stai usando set.Contains()un loop molte volte, spostare l' setelenco dall'hashset può rendere le cose più veloci.
- Come si crea una proprietà di sola lettura?
- Uso un campo contrassegnato come readonlycampo di supporto per una proprietà che ha solo un getter.
- A cosa serve sealed?
- Lo usi per le classi che non devono essere ereditate.
- Qual è l'ultima volta che hai visto un dentista?
- Che cosa?!

2. Richiede molte idee diverse

Quando ti vengono poste domande generali sul tipo di intervista, stai usando la tua memoria per ricordare ciò che hai imparato dai libri o dalla tua pratica sulla lingua e sulla struttura. Potresti pensare un po 'per trovare una risposta, ma non troppo.

D'altra parte, la domanda sulle cinque cose che odi richiede un pensiero più profondo. Non puoi semplicemente ricordare qualcosa che hai imparato dai libri e non puoi trovare nulla per analogia. Invece di essere passivo, devi essere critico e trovare ciò che potrebbe essere spiacevole nella lingua che usi.

3. Richiede tempo

Francamente, ho la mia lista di cinque (in realtà più) cose che odio di C #, ma ci ho pensato per un lungo periodo di tempo. Alcune cose risalgono all'era di .NET Framework 2; la maggior parte dei problemi che ho elencato per .NET Framework 2 non sono più validi perché sono stati rimossi, alcuni con LINQ e tutte queste cose di programmazione funzionale, altri con programmazione dinamica. Non sono sicuro che, senza preparare questa domanda, sarei in grado di trovare tutti e cinque gli elementi durante un'intervista.

Penso che sia difficile a causa della parola cinque . E in misura minore, a causa della parola odio .

Cinque ? E se ne venissi fuori solo con quattro? Non hai risposto alla domanda? E se ne avessi più di cinque? Ora, sul posto, devi capire quali di questi sono i migliori cinque da usare.

Odio è una parola molto negativa. È il tipo di negatività che alle persone viene detto di evitare nelle interviste. Inoltre, penso che sarebbe sembrare strano a un sacco di persone di avere che molte cose che "odio" di una lingua che verrà spesa tutta la programmazione giorno Qualcuno potrebbe anche pensare che è una domanda trabocchetto:. Se essi in realtà non arrivano con cinque cose, saranno squalificati per odiare troppo C # per programmare bene. Sfortunatamente, questo tipo di domanda di trucco perverso non è inaudita nelle interviste.

Invece, potresti chiedere cosa miglioreresti di C # se dipendesse da te? Ciò consente all'intervistato di rispondere con qualsiasi numero di cose. Questo fraseggio scambia anche la negatività della parola "odio" per il "miglioramento" relativamente positivo.

• La maggior parte dei candidati non è così profondamente coinvolta con più di una lingua o paradigma per contrastare . Non lavoro con un altro linguaggio orientato agli oggetti da oltre 5 anni e in quello in cui avevo lavorato (PowerBuilder), ho avuto moltodi peeves con. La maggior parte dei ragazzi appena usciti dal college sono (o pensano di essere) cose in una, forse due lingue, e hanno ricevuto "esposizione" a altre tre o quattro (il che significa che hanno completato almeno un compito a casa che lo richiede ma meno di un semestre intero ovviamente studiandolo). Non è abbastanza conoscenza o esperienza per sapere davvero cosa c'è di sbagliato nella lingua. Trova un lavoro nel mondo reale e questa attenzione si restringe considerevolmente; impari molto di più sulla lingua che ti dà la busta paga rispetto a qualsiasi altra e, nel processo, arrivi ad accettare ciò che la lingua non farà, o fa in modo strano, al punto che non ricordi facendo diversamente.

• La maggior parte dei candidati salvavita di C # che lo confrontano con Java / C / C ++ ne sono piuttosto contenti . C # è stato progettato da zero per fare molte cose meglio di Java (eventi, callback, libreria grafica, lavoro di database). Java a sua volta è stato progettato per essere più facile da usare, e quindi più focalizzato sul codice corretto, rispetto al C ++. Devo ancora incontrare un programmatore C # che vuole tornare al C ++ in qualsiasi ambiente in cui prestazioni esagerate e controllo a livello di circuito prossimo non sono necessità fondamentali.

In altre parole, i See-Sharper lo hanno abbastanza bene, tutto sommato.

Ecco la mia lista:

• Dichiarazioni lambda non visualizzabili / valutabili . Le chiamate ai metodi denominati possono essere collegate al QuickWatch di VS. Così possono le espressioni. Ma lambdas? No (almeno non in VS2010). Rende il debug delle catene Linq un vero lavoro di routine.

• I valori dei parametri opzionali per tipi di riferimento diversi dalla stringa possono essere solo nulli . se stavo creando uno stack di overload, potrei voler utilizzare altre impostazioni predefinite. Potrei essere in grado di impostare un valore predefinito basato su una proprietà o un'espressione semplice basata su un altro parametro. Ma non posso. Quindi il valore di non dover creare uno stack di sovraccarico (che è minore con un assistente di refactoring come ReSharper per gestire la piastra della caldaia) viene ridotto quando le opzioni per i parametri opzionali sono così drasticamente limitate.

• C # sta diventando abbastanza vecchio da avere seri problemi con il codice legacy . Il codice originariamente scritto per 1.1 farebbe rabbrividire chiunque fosse abituato a 4.0. Anche il codice 2.0 manca molto. Allo stesso tempo, sono arrivate librerie di terze parti che fanno sembrare cose come ADO.NET terribilmente primitive (e gran parte del "modello connesso" di ADO.NET è ora un grande anti-pattern). Tuttavia, per compatibilità con le versioni precedenti, .NET si affida al supporto per tutto questo vecchio codice, non osando mai dire qualcosa del tipo "ArrayList era un modo pessimo per farlo, ci dispiace di averlo mai inserito e lo stiamo prendendo out; usa invece List e se hai assolutamente bisogno di un elenco di vari tipi, dichiaralo come List<Object>.

• Regole di istruzione switch seriamente limitate . Probabilmente una delle cose migliori che potrei dire su PowerBuilder è che l'istruzione Choose Case (equivalente a switch) consentiva espressioni booleane basate sulla variabile. Ha anche permesso alle istruzioni switch di fallire anche se avevano codice. Capisco i motivi per cui il secondo è vietato (è più probabile che venga fatto involontariamente che di proposito) ma sarebbe comunque bello di tanto in tanto scrivere una dichiarazione come:

  switch(someInt)
  {
      case < 0: //all negative values enter here
         //...
         break;
      case 0: 
         //...
         break;
      case 1:
         //...
         //no break; continue through to the code for > 1
      case > 1 // all positive values enter here (including 1)
         //...
         break;
  }

• Nessuna interfaccia INumerica . Se è un numero, puoi fare matematica con esso. In molti casi il metodo attuale non deve preoccuparsi esattamente di quali tipi sono collegati; la precisione è responsabilità del chiamante. Tuttavia, non è possibile creare un metodo o una classe generici che possono accettare solo tipi di numeri come GTP.

Suggerirei che parte del problema sia la paura di dare una risposta sbagliata: dici di odiare X, l'intervistatore ama X o pensa che la ragione per odiare X sia idiota, dicendo che pensi che vada bene possa sembrare l'opzione meno controversa.

Probabilmente è anche qualcosa a cui la maggior parte delle persone non ha davvero pensato molto; hanno problemi attuali e problemi passati, problemi passati causati dalla lingua sono finiti e quindi la gente pensa principalmente alla soluzione e non al problema in quanto era più significativo, e pochi avranno un problema attuale causato dalla lingua.

Per un colloquio chiederei solo 1 o 2, ma sono d'accordo, se non puoi nominare alcun limite dello strumento che usi, probabilmente non lo conosci molto bene. Facciamo questa domanda esatta sull'SSIS e aiuta davvero a separare il grano dalla paglia; tutti quelli che abbiamo assunto che hanno risposto a questa domanda si sono trasformati in un grande impiegato. Abbiamo bisogno di persone che abbiano acquisito conoscenze avanzate, non qualcuno che le abbia guardate un paio di volte. E scommetto che è quello che vuoi anche tu.

Penso che sia una domanda valida e il fatto che così tanti non possano rispondere è solo un esempio di quanto siano poveri molti dei candidati per un lavoro. Se qualcuno non è abbastanza analitico per riuscire a capire alcune limitazioni dello strumento, come potrà mai essere abbastanza analitico per risolvere problemi di programmazione difficili?

Si riduce a come hai detto la mancanza di una profonda esperienza con C # e / o la mancanza di esposizione ad altre lingue. Ho intervistato un certo numero di sviluppatori che si consideravano senior e che non potevano rispondere ad alcune domande che anche un leggero graffio sulla superficie di C # avrebbe dovuto rivelare loro.

Senza scavare abbastanza, non raggiungerai i limiti della lingua e vorrai che se ne fossero andati. I miei primi cinque nel caso qualcuno si stia chiedendo

1. La creazione di oggetti immutabili richiede molta cerimonia (al contrario di un linguaggio funzionale in cui gli oggetti sono immutabili per impostazione predefinita).
2. La metaprogrammazione è difficile da fare. Confronta tipo emit con macro Lisp. (I servizi del compilatore aiuteranno molto in questo futuro).
3. I metodi di estensione sono fantastici ... le proprietà di estensione e gli operatori di estensione (in particolare operatori impliciti ed espliciti) sarebbero migliori.
4. I cast espliciti vengono risolti in fase di compilazione anziché in fase di esecuzione.
5. Nessuna corrispondenza di sequenza è molto più pulita del sovraccarico di funzioni.

A suo modo, penso a come sta dicendo; se pensi che sia rotto probabilmente non capisci perché sia ​​così com'è. Potrebbe esserci un buco nella tua conoscenza.

Ironia della sorte, gli intervistatori che pensano di citare "il grande Joel" usando questo come domanda per l'intervista probabilmente mancano piuttosto il punto.

Potrebbero essere riluttanti a rispondere perché potrebbero avere l'impressione che se riescono a elencare 5 cose che odiano di una lingua, l'intervistatore potrebbe voltarsi e dire 'Oh, stiamo cercando C #' ninja 'e tu non sembri per apprezzare la lingua "o" Perché hai fatto domanda per il lavoro se non ti piace la lingua? ".

Gli intervistati hanno molta pressione per rimanere positivi durante le interviste.

Perché le lingue modellano il modo in cui pensiamo . Usando C # ogni giorno, hai preso l'abitudine di pensare e progettare il tuo codice in un modo che aggiri naturalmente i problemi del linguaggio.

Ora lo fai senza pensare, senza nemmeno sapere che lo fai. Questo è il motivo per cui è così difficile sottolineare quali sono le cose cattive. Non c'è dubbio che il giorno in cui hai iniziato a studiare C #, hai trovato molti problemi, ma ora non li vedi più. Le abitudini sono cose potenti. Abitudini di pensiero, anche di più .

Il lato positivo di questo è, se trovi difficile elencare i difetti in C #, deve essere perché sei un buon programmatore C #, ti piace la lingua e la usi più di altre lingue.

Ma se vuoi diventare più capace di vedere i difetti in C #, devi cambiare il tuo modo di pensare. Scopri altri linguaggi di programmazione e abituati a loro. Cerca le lingue più diverse possibili. Sei abituato a digitare staticamente? Prova Python o Ruby. Sei abituato all'oggetto e all'imperativo? Haskell è un altro mondo interamente.

E quando tornerai a C #, sarai come "Perché ho bisogno di cento righe di C # per fare questa semplice cosa che è solo una riga in Haskell?". Odierai molte cose su C #.

• C # non ha tipi di riferimento non annullabili.
• Nessun tipo di dati algebrico.
• Nessuna interpolazione di stringhe.
• La sintassi è eccessivamente prolissa ovunque.
• Nessun sistema macro.
• L'inferenza del tipo è limitata.
• Nessun letterale regexp.
• Nessuna tipizzazione strutturale.
• Scarso supporto per l'immutabilità.
• Le strutture C # sono soggette a errori.
• La libreria di raccolte standard è molto limitata.
• Impossibile definire i vincoli sui parametri dei costruttori.
• Impossibile programmare genericamente con vincoli per gli operatori matematici.
• Nessun "newtype".
• Nessuna suddivisione in array, nessun intervallo letterale.
• Le funzioni non elencano gli effetti collaterali che possono fare come parte del loro tipo. :)

(Naturalmente nessuna lingua può avere tutto. La progettazione della lingua è estremamente difficile e l'aggiunta di tutte le funzionalità nella stessa lingua non può funzionare. Strumenti diversi per scopi diversi.)

Sì, è difficile rispondere bene alla domanda, specialmente durante un'intervista. Ma le persone che possono rispondere dimostrano di averci pensato, di avere una prospettiva.