Dlaczego na pytanie „daj pięć rzeczy, których nienawidzisz w C #”, tak trudno jest odpowiedzieć podczas wywiadu? [Zamknięte]

32

W podcastie 73 Joel Spolsky i Jeff Atwood rozmawiają między innymi o „pięciu rzeczach, których każdy powinien nienawidzić w swoim ulubionym języku programowania”:

Jeśli jesteś zadowolony ze swojego obecnego łańcucha narzędzi, nie ma powodu, aby zmieniać. Jeśli jednak nie możesz wymienić pięciu rzeczy, których nienawidzisz w swoim ulubionym języku programowania, to twierdzę, że nie znasz go wystarczająco dobrze, aby go ocenić. Dobrze jest być świadomym alternatyw i mieć zdrowe oko krytyczne na to, czego używasz.

Z ciekawości zadałem to pytanie każdemu kandydatowi, z którym przeprowadziłem wywiad. Żaden z nich nie był w stanie zacytować przynajmniej jednej rzeczy, której nienawidzi w C # ¹.

Czemu? Co jest takiego trudnego w tym pytaniu? Czy ze względu na stresujący kontekst rozmowy respondenci nie mogą odpowiedzieć na to pytanie?

Czy jest coś w tym pytaniu, co czyni go złym do rozmowy kwalifikacyjnej?


Oczywiście nie oznacza to, że C # jest idealny. Mam listę pięciu rzeczy, których nienawidzę w C #:

  • Brak zmiennej liczby typów w nazwach ogólnych (podobnie jak w paramsprzypadku argumentów).
    Action<T>,
    Action<T1, T2>,
    Action<T1, T2, T3>,
          ⁞ Poważnie ?!
    Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>

  • Brak wsparcia dla jednostek miary, jak w F #.

  • Brak właściwości tylko do odczytu. Pisanie private readonlypola zaplecza za każdym razem, gdy chcę właściwość tylko do odczytu, jest nudne.

  • Brak właściwości o wartościach domyślnych. I tak, wiem, że mogę zainicjować je w konstruktorze bez parametrów i wywołać je ze wszystkich innych konstruktorów. Ale nie chcę.

  • Wielokrotne dziedziczenie. Tak, powoduje zamieszanie i nie potrzebujesz go w większości przypadków. Nadal jest użyteczny w niektórych (bardzo rzadkich) przypadkach, a zamieszanie dotyczy również (i zostało rozwiązane w języku C #) klasy, która dziedziczy kilka interfejsów zawierających metody o tej samej nazwie.

Jestem prawie pewien, że ta lista jest daleka od ukończenia, i jest o wiele więcej punktów do podkreślenia, a zwłaszcza o wiele lepsze niż moje.


¹ Kilka osób skrytykowało niektóre zestawy w .NET Framework lub brak niektórych bibliotek w frameworku lub skrytykowało CLR. To się nie liczy, ponieważ pytanie dotyczyło samego języka i chociaż potencjalnie mógłbym zaakceptować odpowiedź na coś negatywnego w rdzeniu .NET Framework (na przykład coś takiego jak fakt, że nie ma wspólnego interfejsu TryParse, więc jeśli chcesz parsować ciąg do kilku typów, musisz powtórzyć się dla każdego typu), odpowiedź na temat JSON lub WCF jest całkowicie nie na temat.

Arseni Mourzenko
źródło
52
Why the question “give five things you hate about C#” is so difficult to answerPonieważ jest to pytanie z listy, a zły mod
zamknąłby
6
@Yannis Rizos: dobra uwaga. BTW, wpisując to pytanie w tytule, Stack Overflow ostrzega, że „Pytanie, które zadajesz, wydaje się subiektywne i prawdopodobnie zostanie zamknięte”.
Arseni Mourzenko,
5
Być może przestrzeń pamięci twojego mózgu na rzeczy, których nienawidzisz w językach programowania, jest w większości wypełniona aspektami innych języków, z którymi masz do czynienia.
whatsisname
9
Prawdopodobnie dlatego, że większość ludzi nie jest nienawistna. Nienawiść jest dość mocnym słowem dla większości ludzi. Sądząc po liście naprawdę, naprawdę trywialnych przedmiotów, których „nienawidzisz” w C #, człowieku, tak naprawdę nie chciałbym być nigdzie w pobliżu, gdy istnieje jakiś powód, aby coś nienawidzić. Podejrzewam, że twoja głowa wybuchłaby. Podejrzewam również, że wymyślenie listy jest trudne dla większości ludzi, ponieważ trzeba było naprawdę rozciągnąć się, aby wymyślić listę i miałeś dni, aby o tym pomyśleć.
Dunk
19
Czy zauważyłeś, że we wszystkich pozycjach na liście brakuje czegoś, a nie czegoś źle zrobionego? Moim zdaniem nie udało ci się zadać pytania podczas rozmowy kwalifikacyjnej. Każdy może wymienić funkcje brakujące w tym języku i zadeklarować, że jest to powód do nienawiści, ale najbardziej znienawidzonym językiem będzie ten, który ma wszystkie funkcje.
Stilgar,

Odpowiedzi:

42

Gdybym musiał zgadywać:

  1. Niektórym programistom brakuje różnorodnej znajomości języka. Trudno jest dostrzec, że coś jest nie tak z językiem, jeśli nie wiesz, że istnieją lepsze rzeczy.

  2. Niektórzy programiści są zwykłymi małpami kodowymi. Ledwo analizują stojące przed nimi problemy, nie mówiąc już o tym, jak ich język programowania mógłby być lepszy.

  3. Niewiele osób jest szczególnie krytycznych. Widzą zalety i funkcje, a nie niedociągnięcia. Trudno im przejść do takiego sposobu myślenia, jeśli wywiad nie idzie w tym kierunku.

  4. Przynajmniej w tym miejscu nadmierna krytyczność postrzegana jest jako śmiertelna wada osobowości. Zamiast być „wnikliwym deweloperem, który zawsze szuka lepszych sposobów robienia rzeczy” (jak niektóre obszary, w których mieszkałem), są „dupkiem, który nienawidzi wszystkiego”. Nawet ludzie, którzy potrafią myśleć o rzeczach, których nienawidzą w tym języku, mogą odłożyć się na rozmowę kwalifikacyjną, by wydawać się mniej ostra.

Telastyn
źródło
22
Jeśli chodzi o nr 2, wolimy Software Simians , Sir.
toniedzwiedz
@Tom Myślałem, że to pan programmatoribus .
Stefano Borini,
9
@Telastyn nie powinien zawierać pięciu punktów w odpowiedzi?
Ben Jackson,
# 4 przyszło mi do głowy od razu, szczególnie w środowiskach pracy, które są zaangażowane w używanie C #. Biorąc pod uwagę częste rozmowy kwalifikacyjne i porady dotyczące zachowania w miejscu pracy, pytanie o to podczas rozmowy kwalifikacyjnej może wydawać się przynętą na złapanie „złych postaw”, które mogą sprawić, że nie będą chcieli zatrudnić tej osoby. W przeciwieństwie do postępowania sądowego, w rozmowach o pracę prawdopodobnie nie jest skuteczną obroną. ;-)
Dronz
35

Wyobrażam sobie, że na pytanie trudno jest odpowiedzieć podczas wywiadu, ponieważ:

  1. Naprawdę nieoczekiwane

  2. Wymaga dużo myślenia i myślenia w zupełnie inny sposób niż podczas wywiadu,

  3. Na ogół trudno jest odpowiedzieć w krótkim czasie (chyba że zostanie przygotowany przed rozmową kwalifikacyjną).

1. To nieoczekiwane

Nieoczekiwane pytania są naprawdę trudne, szczególnie w stresującym kontekście. Wyobraź sobie następujące okno dialogowe podczas wywiadu:

- Jaka jest różnica między HashSet<T>i List<T>?
- Hashset jest zoptymalizowany w taki sposób, że wyszukiwanie elementu jest bardzo szybkie. Na przykład, jeśli używasz set.Contains()w pętli wiele razy, przeniesienie setz listy na zestaw skrótów może przyspieszyć.
- Jak utworzyć właściwość tylko do odczytu?
- Używam pola oznaczonego jako readonlypole zaplecza dla nieruchomości, która ma tylko getter.
- Do czego służy sealed?
- Używasz go dla klas, których nie można dziedziczyć.
- Kiedy ostatni raz widziałeś dentystę?
- Co?!

2. Wymaga to różnego myślenia

Kiedy zadawane są ogólne pytania typu wywiad, używasz pamięci, aby przypomnieć sobie, czego nauczyłeś się z książek lub z praktyki na temat języka i frameworka. Możesz trochę pomyśleć, aby znaleźć odpowiedź, ale nie za dużo.

Z drugiej strony pytanie o pięć rzeczy, których nienawidzisz, wymaga głębszego przemyślenia. Nie możesz po prostu przypomnieć sobie czegoś, czego nauczyłeś się z książek, i nie możesz niczego znaleźć przez analogię. Zamiast być biernym, musisz być krytykiem i znaleźć to, co może być nieprzyjemne w języku, którego używasz.

3. Wymaga czasu

Szczerze mówiąc, mam swoją listę pięciu (właściwie więcej) rzeczy, których nienawidzę w C #, ale myślałem o tym przez długi okres czasu. Kilka rzeczy pochodzi z ery .NET Framework 2; większość problemów wymienionych dla .NET Framework 2 nie jest już ważna, ponieważ zostały usunięte, niektóre z LINQ i wszystkimi innymi funkcjami programowania, inne z programowaniem dynamicznym. Nie jestem pewien, czy bez przygotowania tego pytania byłbym w stanie znaleźć wszystkie pięć elementów podczas wywiadu.

Arseni Mourzenko
źródło
3
Myślę, że ogólnie masz rację, ale programowanie w określonym języku przez wystarczająco długi czas po prostu sprawi , że nie będziesz cierpiał na pewne „osobliwości” tego. Jakaś lista hitów. A przynajmniej mam jeden dla każdego języka / platformy, z której kiedykolwiek korzystałem. A może jestem po prostu rozpieszczona i wybredna.
K.Steff,
2
@ K.Steff: „Lista hitów” to dla niej idealna nazwa :). Z pewnością mogę wymyślić ponad pięć problemów nawet z moją ulubioną platformą; jeśli zapytasz mnie o język, który mi się nie podoba, ale zostałem zmuszony go używać (np. Java lub Python), prawdopodobnie mógłbym trwać godzinami: P.
Tikhon Jelvis,
1
To, czy potrafisz łatwo zapamiętać rzeczy, których nienawidzisz w danym języku, będzie zależeć od tego, jak kłopotliwe są „osobliwości” w stosunku do innych rzeczy, z którymi masz do czynienia. Na przykład większość mojej pracy dotyczy interakcji z pewnym (i szczególnie okropnym) obcym systemem i jego interfejsem API. Większość chwytów na temat C # / .NET jest blada w porównaniu i zostaje zepchnięta na myśl.
Dan Lyons,
To wspaniałe, że możesz śledzić „listę przebojów” dla każdego języka / platformy i nosić ją ze sobą, ponieważ programujesz w określonym języku przez „wystarczającą ilość czasu”. Są też inni, którzy po prostu nie zadają sobie trudu przeniesienia tych problemów po zaprogramowaniu na „wystarczająco dużo czasu”. To, co robią inni, polega na znalezieniu rozwiązania problemów na ich liście wyników, a następnie nigdy więcej nie trzeba się martwić o problem z listą wyników, ponieważ sprawili, że zniknął. Jeśli przewożenie listy było wystarczająco trudne, to musieli pomyśleć, że to wystarczający problem, aby poświęcić czas na rozwiązanie ich upodobań.
Dunk
21

Myślę, że to trudne ze względu na słowo piąte . I w mniejszym stopniu z powodu słowa nienawiść .

Pięć ? Co jeśli wymyślisz tylko cztery? Nie odpowiedziałeś na pytanie? Co jeśli masz więcej niż pięć? Teraz na miejscu musisz dowiedzieć się, który z nich jest najlepszy do użycia.

Nienawiść to bardzo negatywne słowo. Jest to rodzaj negatywności, której ludzie powinni unikać podczas wywiadów. Co więcej, myślę, że to brzmi dziwnie, wielu ludzi ma, że wiele rzeczy, które „hate” o języku będą spędzać całe programowanie dniową u niektórych osób może nawet pomyśleć, że to podchwytliwe pytanie. Jeśli oni rzeczywiście mają pochodzić z pięcioma rzeczami, zostaną zdyskwalifikowani za zbytnie nienawidzenie C #, aby dobrze się programować. Niestety, tego rodzaju przewrotne pytanie o sztuczkę nie jest niespotykane w wywiadach.

Zamiast tego możesz zapytać Co poprawiłbyś o C #, gdyby to zależało od ciebie? To pozwala rozmówcy odpowiedzieć na dowolną liczbę rzeczy. To wyrażenie zamienia również negatywność słowa „nienawiść” w stosunku do względnie pozytywnego „ulepszenia”.

Kyralessa
źródło
2
Twój punkt przeciwko „piątce” jest dobry - wiele osób prawdopodobnie będzie miało kontinuum rzeczy, których nie lubią w różnym stopniu, ale jedynym sposobem, w jaki mogliby zdecydować, które rzeczy reprezentują piątkę, byłoby uszeregowanie wszystkiego, co może być blisko. Jeśli ktoś niedawno miał problem z czymś, co generalnie jest niewielką irytacją, być może będzie musiał zastanowić się przez chwilę, czy to naprawdę powinno znaleźć się w pierwszej piątce, czy też tylko przyszło mu to do głowy, ponieważ to był tak niedawno problem. Co więcej, C # jest tak ściśle powiązane z .NET, że trudno jest powiedzieć, za co winić. Na przykład ...
supercat
1
... Byłbym przekonany, że wszystkie języki powinny zagwarantować, że jeśli konstruktor wyrzuci, częściowo skonstruowany obiekt otrzyma Disposed, ale przy braku wymogu wymuszania tego przez wszystkie języki, można argumentować, że języki, które to robią, wzbudzają fałszywe oczekiwania. Może być zatem niejasne, czy trudność uniknięcia wycieku zasobów w przypadku awarii konstruktora C # należy winić za C # lub CLS.
supercat
14
  • Większość kandydatów nie jest tak głęboko zaangażowana w więcej niż jeden język lub paradygmat, aby się przeciwstawić . Nie pracuję z innym językiem obiektowym od ponad 5 lat, a w tym, w którym pracowałem (PowerBuilder), miałem dużorękawów z. Większość facetów świeżo po studiach jest (lub myśli, że są) gorącymi rzeczami w jednym, może w dwóch językach, i otrzymali „kontakt” z trzema lub czterema innymi (co oznacza, że ​​wykonali co najmniej jedno zadanie domowe wymagające tego, ale mniej niż pełny semestr oczywiście studiowanie). To za mało wiedzy lub doświadczenia, aby naprawdę wiedzieć, co jest nie tak z językiem. Znajdź pracę w prawdziwym świecie, a ta koncentracja znacznie się zawęzi; dowiadujesz się znacznie więcej o języku, który daje ci wypłatę niż jakikolwiek inny, a następnie przychodzisz do zaakceptowania tego, czego ten język nie zrobi lub robi w dziwny sposób, do tego stopnia, że ​​nie pamiętasz robić to inaczej.

  • Większość zadowolonych z języka C # kandydatów, którzy porównują go do Java / C / C ++, jest z tego bardzo zadowolona . C # został zaprojektowany od podstaw, aby robić wiele rzeczy lepiej niż Java (zdarzenia, wywołania zwrotne, biblioteka grafiki, praca z bazą danych). Z kolei Java została zaprojektowana tak, aby była łatwiejsza w użyciu, a więc bardziej skupiona na poprawnym kodzie niż C ++. Jeszcze nie spotkałem programisty C #, który chce wrócić do C ++ w każdym środowisku, w którym zawrotna wydajność i kontrola na poziomie zbliżonym do obwodu nie są krytycznymi potrzebami.

Innymi słowy, See-Sharpers mają to całkiem niezłe, biorąc pod uwagę wszystko.

Oto moja lista:

  • Nie można oglądać / oceniać instrukcji lambda . Wywołania nazwanych metod można podłączyć do QuickWatch VS. Podobnie wyrażenia. Ale lambdas? Nie (przynajmniej nie w VS2010). Sprawia, że ​​debugowanie łańcuchów Linq staje się prawdziwym obowiązkiem.

  • Opcjonalne wartości parametrów dla typów referencyjnych innych niż łańcuch mogą mieć wartość null . gdybym tworzył stos przeciążenia, może chciałbym użyć innych ustawień domyślnych. Mogę być w stanie ustawić jedną wartość na podstawie właściwości lub prostego wyrażenia na podstawie innego parametru. Ale nie mogę. Tak więc wartość braku konieczności tworzenia stosu przeciążenia (co jest niewielkie w przypadku asystenta refaktoryzacji, takiego jak ReSharper do obsługi płyty kotłowej) jest zmniejszona, gdy opcje parametrów opcjonalnych są tak drastycznie ograniczone.

  • C # staje się wystarczająco stary, aby mieć poważne problemy ze starszym kodem . Kod pierwotnie napisany dla 1.1 sprawiłby, że każdy, kto przyzwyczaił się do wersji 4.0, zaczął się przerażać. Nawet kod 2.0 bardzo często mija. W tym samym czasie pojawiły się biblioteki innych firm, które sprawiają, że takie rzeczy jak ADO.NET wydają się żałośnie prymitywne (a duża część „podłączonego modelu” ADO.NET jest teraz dużym anty-wzorcem). Jednak ze względu na zgodność z poprzednimi wersjami .NET obsługuje cały ten stary, zły kod, nigdy nie ośmielając się powiedzieć czegoś takiego: „ArrayList był kiepskim sposobem na zrobienie tego, przykro nam, że to zrobiliśmy i bierzemy obecnie, użyj Listy zamiast, a jeśli absolutnie potrzebujesz listy różnych typów, zadeklaruj ją jako List<Object>.

  • Poważnie ograniczone reguły instrukcji switch . Prawdopodobnie jedną z najlepszych rzeczy, które mogę powiedzieć o PowerBuilder, jest to, że instrukcja Select Case (odpowiednik przełącznika) zezwala na wyrażenia logiczne na podstawie zmiennej. Pozwoliło to również na przewrócenie instrukcji switch, nawet jeśli miały kod. Rozumiem powody, dla których ten drugi jest niedozwolony (jest bardziej prawdopodobne, że zostanie to zrobione nieumyślnie niż celowo), ale od czasu do czasu miło byłoby napisać takie zdanie:

    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;
    }
  • Brak interfejsu INumeric . Jeśli jest to liczba, możesz z nią matematyki. W wielu przypadkach rzeczywista metoda nie musi dbać o to, które typy są podłączone; precyzja jest obowiązkiem osoby dzwoniącej. Nie można jednak utworzyć ogólnej metody lub klasy, która może akceptować tylko typy liczb jako GTP.
KeithS
źródło
3
„Większość zadowolonych z języka C # kandydatów, którzy porównują go do Java / C / C ++, jest z tego bardzo zadowolona”. Tak myślałem. C # nie ma wiele do nienawiści, ponieważ pozwala skupić się na rozwiązaniu problemu biznesowego, a nie na rozwiązaniu problemu technicznego. Największą przeszkodą, jaką mam z tym językiem, jest to, że nie mogę używać ciągów zasobów w testach przypadków przełączania, ponieważ są one technicznie zmienne, a nie stałe.
Stephen
4
Trochę o ogólnych i kontenerach - Przydatny przykład z super i niejasnością z rozszerzeniami w Generics? wyjaśnia to trochę. Przypisanie Bag<Fruit> bag = Bag<Huckleberry>oznaczałoby, że możesz zrobić, bag.add(new Watermelon())co nie mogło go utrzymać.
4
+1 dla No INumeric. Rzadkie, ale irytujące.
jmoreno
Załóżmy, że Thing<out T>ma pole statyczne, do którego dostęp ma zarówno metoda instancji, jak i metoda statyczna. Jeśli a Thing<Cat>jest przekazywane do metody, która oczekuje a Thing<Animal>, i ta metoda wywołuje wspomniane powyżej wystąpienie i metody statyczne w Thing<Animal>odniesieniu, do jakich pól statycznych powinny mieć dostęp te metody?
supercat
11

Sugerowałbym, że częścią problemu jest strach przed udzieleniem złej odpowiedzi - mówisz, że nienawidzisz X, ankieter uwielbia X lub myślisz, że twój powód nienawidzenia X jest idiotyczny, mówiąc, że uważasz, że to w porządku może wydawać się mniej kontrowersyjną opcją.

Jest to prawdopodobnie coś, o czym większość ludzi tak naprawdę nie zastanawiała się; mają bieżące problemy i problemy z przeszłości, problemy z przeszłości, które były spowodowane przez język, zostały zakończone, więc ludzie głównie myślą o rozwiązaniu, a nie o problemie, ponieważ był on bardziej znaczący, a niewielu będzie miało obecny problem spowodowany przez język.

jmoreno
źródło
7

Na rozmowę poprosiłbym tylko o 1 lub 2, ale zgadzam się, jeśli nie potrafisz wymienić żadnych ograniczeń używanego narzędzia, to prawdopodobnie nie znasz go zbyt dobrze. Zadajemy dokładnie to pytanie dotyczące SSIS i naprawdę pomaga oddzielić pszenicę od plew; wszyscy, których zatrudniliśmy, którzy dobrze odpowiedzieli na to pytanie, stali się świetnym pracownikiem. Potrzebujemy ludzi, którzy posiadają zaawansowaną wiedzę, a nie kogoś, kto spojrzał na nią kilka razy. Założę się, że tego też chcesz.

Myślę, że to ważne pytanie, a fakt, że tak wielu nie mogło na nie odpowiedzieć, jest tylko przykładem tego, jak bardzo biedni jest wielu kandydatów do pracy. Jeśli ktoś nie jest wystarczająco analityczny, aby zrozumieć pewne ograniczenia tego narzędzia, to w jaki sposób będzie wystarczająco analityczny, aby rozwiązać trudne problemy programistyczne?

HLGEM
źródło
1
+1 Pięć jest zastraszające, dlatego 1 lub 2 prawdopodobnie otrzymają więcej odpowiedzi.
Laurent Couvidou
2
Nienawiść jest zupełnie inna niż ograniczenie ......
mattnz
4

Sprowadza się to do tego, jak powiedziałeś, brak dogłębnego doświadczenia z C # i / lub brak kontaktu z innymi językami. Przeprowadziłem wywiad z wieloma programistami, którzy uważali się za starszych, którzy nie byli w stanie odpowiedzieć na pytania, które nawet lekkie rysy na powierzchni C # powinny były im ujawnić.

Bez wystarczającego kopania nie osiągniesz granic języka i nie żałujesz, że ich nie ma. Moja pierwsza piątka na wypadek, gdyby ktoś się zastanawiał

  1. Tworzenie obiektów niezmiennych wymaga dużo ceremonii (w przeciwieństwie do funkcjonalnego języka, w którym obiekty są domyślnie niezmienne).
  2. Metaprogramowanie jest trudne. Porównaj typ emit do makr Lisp. (Usługi kompilatora bardzo w tym pomogą).
  3. Metody rozszerzenia są świetne ... lepsze byłyby właściwości rozszerzenia i operatory rozszerzenia (w szczególności operatory niejawne i jawne).
  4. Jawne rzutowania są rozstrzygane w czasie kompilacji zamiast w czasie wykonywania.
  5. Bez dopasowania sekwencji jest o wiele czystsze niż przeciążanie funkcji.
Michael Brown
źródło
Zgadzam się z Twoimi dwoma pierwszymi punktami, ale wzdrygam się na myśl o niejawnej konwersji.
CodesInChaos
3

Myślę w jego kręgu o tym, co mówi; jeśli uważasz, że jest zepsuty, prawdopodobnie nie rozumiesz, dlaczego tak jest. W twojej wiedzy może być dziura.

Jak na ironię, ankieterzy, którzy myślą, że cytują „wielkiego Joela”, używając go jako pytania do wywiadu, prawdopodobnie raczej nie rozumieją tego.

Ian
źródło
Twierdziłbym, że nie zawsze tak jest. Np. Douglas Crockford mówi w „JavaScript: The Good Parts”, że powinieneś unikać pewnych funkcji języka i nie sądzę, żeby miał na myśli, że są „zbyt hardkorowi”, aby ich używać.
K.Steff,
10
Myślę, że mówi coś przeciwnego - jeśli uważasz, że platforma nie jest w żaden sposób zepsuta, nie znasz jej wystarczająco dobrze. Chodzi mu o to, że dobrze jest trzymać się jednej platformy, o ile nie jesteś ślepy na jej wady.
Tikhon Jelvis,
3

Mogą niechętnie odpowiadać, ponieważ mogą mieć wrażenie, że jeśli potrafią wymienić 5 rzeczy, których nienawidzą w języku, ankieter może się odwrócić i powiedzieć „Och, szukamy ninja C #”, a ty nie wydajesz się polubić język ”lub„ Dlaczego złożyłeś podanie o pracę, jeśli nie podoba ci się ten język? ”.

Respondenci są pod dużą presją, aby pozostać pozytywnymi podczas wywiadów.

James
źródło
jeśli nienawidzę czegoś w języku, to nie znaczy, że nienawidzę tego języka. Na pytanie <del> można </del> również należy odpowiedzieć pozytywnie. Dlaczego potrzebujemy HTML5, jeśli niczego nie nienawidzimy w HTML4? :)
e-MEE,
3

Ponieważ języki kształtują nasz sposób myślenia . Używając C # na co dzień, przyzwyczaiłeś się do myślenia i projektowania kodu w sposób, który naturalnie rozwiązuje problemy języka.

Robisz to teraz bez zastanowienia, nawet nie wiedząc, że to robisz. Dlatego tak trudno jest wskazać, jakie są złe rzeczy. Bez wątpienia w dniu, w którym zacząłeś uczyć się języka C #, natrafiłeś na wiele problemów, ale teraz już ich nie widzisz. Nawyki to potężne rzeczy. Zwyczaje myślowe, a nawet więcej .

Pozytywną stroną tego jest to, że jeśli trudno ci wymienić błędy w C #, to musi być tak, że jesteś dobrym programistą w C #, lubisz język i używasz go bardziej niż innych języków.

Ale jeśli chcesz lepiej widzieć wady w C #, musisz zmienić sposób myślenia. Dowiedz się więcej języków programowania i przyzwyczaj się do nich. Celuj w możliwie różne języki. Jesteś przyzwyczajony do pisania statycznego? Wypróbuj Python lub Ruby. Jesteś przyzwyczajony do obiektowego i imperatywnego? Haskell to zupełnie inny świat.

A kiedy wrócisz do C #, pomyślisz: „Dlaczego potrzebuję stu linii C #, aby zrobić tę prostą rzecz, która jest tylko jedną linią w Haskell?”. Nienawidzisz wielu rzeczy o C #.

  • C # nie ma typów zerowalnych.
  • Brak algebraicznych typów danych.
  • Brak interpolacji ciągów.
  • Składnia jest wszędzie zbyt rozbudowana.
  • Brak systemu makr.
  • Wnioskowanie typu jest ograniczone.
  • Brak literałów regularnych.
  • Bez pisania strukturalnego.
  • Słabe poparcie dla niezmienności.
  • Struktury C # są podatne na błędy.
  • Standardowa biblioteka zbiorów jest bardzo ograniczona.
  • Nie można zdefiniować ograniczeń parametrów konstruktorów.
  • Nie można programować ogólnie z ograniczeniami dla operatorów matematycznych.
  • Brak „nowego typu”.
  • Bez dzielenia tablic, bez dosłowności zakresu.
  • Funkcje nie wymieniają skutków ubocznych, które mogą wywoływać w ramach swojego typu. :)

(Oczywiście żaden język nie może mieć wszystkiego. Projektowanie języka jest niezwykle trudne, a dodanie każdej funkcji do tego samego języka nie działa. Różne narzędzia do różnych celów.)

Tak, na pytanie trudno odpowiedzieć dobrze, szczególnie podczas wywiadu. Ale ludzie, którzy potrafią na to odpowiedzieć, dowodzą, że pomyśleli o tym, że mają jakąś perspektywę.

Eldritch Conundrum
źródło
+1. Doskonały punkt Rzeczywiście, wiele rzeczy, których nienawidzę w C #, wynika z faktu, że inne języki nie mają tych samych wad. Brak prawdziwych krotek (tj. Niemożność zrobienia (a, b) = this.something();czegoś podobnego w Pythonie) jest pierwszą rzeczą, jaka przychodzi mi do głowy.
Arseni Mourzenko