Dlaczego wnioskowanie typu jest przydatne?

Czytam kod znacznie częściej niż piszę kod i zakładam, że większość programistów pracujących nad oprogramowaniem przemysłowym to robi. Zakładam, że zaletą wnioskowania typu jest mniejsza szczegółowość i mniej napisany kod. Ale z drugiej strony, jeśli czytasz kod częściej, prawdopodobnie będziesz chciał kodu czytelnego.

Kompilator określa typ; istnieją na to stare algorytmy. Ale prawdziwe pytanie brzmi: dlaczego ja, programista, chciałbym wnioskować o rodzaju moich zmiennych podczas czytania kodu? Czy to nie jest szybsze, aby ktokolwiek po prostu czytał ten typ, niż zastanawiał się, jaki on jest?

Edycja: Podsumowując, rozumiem, dlaczego jest przydatny. Ale w kategorii funkcji językowych widzę to w wiadrze z przeciążeniem operatora - przydatne w niektórych przypadkach, ale wpływające na czytelność, jeśli są nadużywane.

Rzućmy okiem na Javę. Java nie może mieć zmiennych z wnioskowanymi typami. Oznacza to, że często muszę przeliterować typ, nawet jeśli dla czytelnika jest zupełnie oczywiste, jaki jest typ:

int x = 42;  // yes I see it's an int, because it's a bloody integer literal!

// Why the hell do I have to spell the name twice?
SomeObjectFactory<OtherObject> obj = new SomeObjectFactory<>();

A czasem pisanie całego typu jest po prostu denerwujące.

// this code walks through all entries in an "(int, int) -> SomeObject" table
// represented as two nested maps
// Why are there more types than actual code?
for (Map.Entry<Integer, Map<Integer, SomeObject<SomeObject, T>>> row : table.entrySet()) {
    Integer rowKey = entry.getKey();
    Map<Integer, SomeObject<SomeObject, T>> rowValue = entry.getValue();
    for (Map.Entry<Integer, SomeObject<SomeObject, T>> col : rowValue.entrySet()) {
        Integer colKey = col.getKey();
        SomeObject<SomeObject, T> colValue = col.getValue();
        doSomethingWith<SomeObject<SomeObject, T>>(rowKey, colKey, colValue);
    }
}

Pełne pisanie statyczne przeszkadza mi, programistom. Większość adnotacji typu to powtarzające się wypełnianie wierszy, pozbawione treści zwroty tego, co już wiemy. Lubię jednak pisanie statyczne, ponieważ może to naprawdę pomóc w wykrywaniu błędów, więc używanie pisania dynamicznego nie zawsze jest dobrą odpowiedzią. Wnioskowanie o typach jest najlepsze z obu światów: mogę pominąć niepotrzebne typy, ale nadal mam pewność, że mój program (typ) się sprawdzi.

Chociaż wnioskowanie typu jest naprawdę przydatne w przypadku zmiennych lokalnych, nie powinno się go stosować w publicznych interfejsach API, które muszą być jednoznacznie udokumentowane. A czasem typy naprawdę mają kluczowe znaczenie dla zrozumienia, co dzieje się w kodzie. W takich przypadkach głupotą byłoby polegać wyłącznie na wnioskowaniu typu.

Istnieje wiele języków, które obsługują wnioskowanie typu. Na przykład:

• C ++. Te autowyzwalacze słów kluczowych wpisać wnioskowanie. Bez niego wypisywanie rodzajów lambdów lub wpisów w pojemnikach byłoby piekłem.

• DO#. Można zadeklarować zmienne var, co wyzwala ograniczoną formę wnioskowania o typie. Nadal zarządza większością przypadków, w których chcesz wnioskować o typie. W niektórych miejscach możesz całkowicie pominąć ten typ (np. W lambda).

• Haskell i każdy język w rodzinie ML. Chociaż zastosowany tutaj specyficzny sposób wnioskowania o typie jest dość potężny, nadal często widzisz adnotacje o typach funkcji z dwóch powodów: Pierwszy to dokumentacja, a drugi to sprawdzenie, czy wnioskowanie o typach rzeczywiście znalazło oczekiwane typy. Jeśli występuje rozbieżność, prawdopodobnie występuje jakiś błąd.

Prawdą jest, że kod jest odczytywany znacznie częściej niż jest zapisywany. Jednak czytanie wymaga również czasu, a dwa ekrany kodu są trudniejsze w nawigacji i czytaniu niż jeden ekran kodu, dlatego musimy ustalić priorytet, aby spakować najlepszy użyteczny stosunek informacji / wysiłku odczytu. Jest to ogólna zasada UX: zbyt duża ilość informacji jednocześnie przytłacza i faktycznie obniża efektywność interfejsu.

I z mojego doświadczenia wynika , że często dokładny typ nie jest (to) ważny. Na pewno czasami zagnieżdżać wyrażenia: x + y * z, monkey.eat(bananas.get(i)), factory.makeCar().drive(). Każde z nich zawiera podwyrażenia, których wynikiem jest wartość, której typ nie jest zapisany. Ale są całkowicie jasne. Nie przeszkadza nam pozostawienie tego typu bez opisu, ponieważ łatwo jest go zrozumieć z kontekstu, a jego zapisanie przyniosłoby więcej szkody niż pożytku (zaśmiecenie zrozumienia przepływu danych, zabranie cennego ekranu i krótkotrwałej pamięci).

Jednym z powodów, dla których nie zagnieżdżaj wyrażeń, tak jak nie ma jutra, jest to, że linie stają się długie, a przepływ wartości staje się niejasny. Wprowadzenie zmiennej tymczasowej pomaga w tym, narzuca porządek i nadaje nazwę częściowemu wynikowi. Jednak nie wszystko, co korzysta z tych aspektów, również korzysta z tego, że określono jego typ:

user = db.get_poster(request.post['answer'])
name = db.get_display_name(user)

Czy ma znaczenie, czy obiekt userjest obiektem, liczbą całkowitą, łańcuchem, czy czymś innym? W większości przypadków tak nie jest, wystarczy wiedzieć, że reprezentuje użytkownika, pochodzi z żądania HTTP i służy do pobrania nazwy wyświetlanej w prawym dolnym rogu odpowiedzi.

A gdy ma to znaczenie, autor może napisać ten typ. Jest to swoboda, z której należy korzystać w sposób odpowiedzialny, ale to samo dotyczy wszystkiego, co może poprawić czytelność (nazwy zmiennych i funkcji, formatowanie, projektowanie interfejsu API, białe znaki). I rzeczywiście, konwencja w Haskell i ML (gdzie wszystko można wywnioskować bez dodatkowego wysiłku) polega na wypisaniu typów funkcji funkcji nielokalnych, a także zmiennych lokalnych i funkcji, gdy jest to właściwe. Tylko nowicjusze pozwalają wywnioskować każdy typ.

Myślę, że wnioskowanie na temat typu jest dość ważne i powinno być obsługiwane w każdym nowoczesnym języku. Wszyscy rozwijamy się w IDE i mogą one bardzo pomóc na wypadek, gdybyś chciał poznać wyprowadzony typ, tylko kilku z nas włamuje się vi. Pomyśl na przykład o gadatliwości i kodzie ceremonii w Javie.

  Map<String,HashMap<String,String>> map = getMap();

Ale możesz powiedzieć, że to w porządku, moje IDE mi pomoże, to może być ważny punkt. Jednak niektóre funkcje nie byłyby dostępne bez pomocy wnioskowania o typie, na przykład typy anonimowe w języku C #.

 var person = new {Name="John Smith", Age = 105};

LINQ nie byłby tak miły, jak to jest teraz bez pomocy typu wnioskowania, Selectna przykład

  var result = list.Select(c=> new {Name = c.Name.ToUpper(), Age = c.DOB - CurrentDate});

Ten anonimowy typ zostanie starannie wywnioskowany ze zmiennej.

Nie podoba mi się wnioskowanie o typach zwrotnych, Scalaponieważ myślę, że twój punkt dotyczy tutaj, powinno być dla nas jasne, co zwraca funkcja, abyśmy mogli płynniej korzystać z interfejsu API

Myślę, że odpowiedź na to pytanie jest bardzo prosta: oszczędza czytania i pisania zbędnych informacji. Zwłaszcza w językach zorientowanych obiektowo, w których po obu stronach znaku równości jest czcionka.

Co również informuje, kiedy należy lub nie należy jej używać - gdy informacje nie są zbędne.

Załóżmy, że ktoś widzi kod:

someBigLongGenericType variableName = someBigLongGenericType.someFactoryMethod();

Jeśli można someBigLongGenericTypeto przypisać na podstawie typu zwracanego someFactoryMethod, to jak prawdopodobne jest, aby ktoś czytający kod zauważył, jeśli typy nie pasują dokładnie, i jak łatwo ktoś, kto zauważył rozbieżność, mógł rozpoznać, czy było to zamierzone, czy nie?

Umożliwiając wnioskowanie, język może zasugerować komuś, kto czyta kod, że gdy zostanie wyraźnie określony typ zmiennej, osoba ta powinna spróbować znaleźć przyczynę. To z kolei pozwala osobom, które czytają kod, lepiej skoncentrować swoje wysiłki. Jeśli natomiast w zdecydowanej większości przypadków, gdy określony jest typ, zdarza się, że jest dokładnie taki sam, jak to, co można by wywnioskować, to ktoś, kto czyta kod, może być mniej podatny na zauważenie, że jest on nieco inny .

Widzę, że jest już wiele dobrych odpowiedzi. Niektóre z nich powtórzę, ale czasami po prostu chcesz wyrazić swoje własne słowa. Skomentuję kilka przykładów z C ++, ponieważ jest to język, który znam najbardziej.

To, co jest konieczne, nigdy nie jest nierozsądne. Wnioskowanie typu jest konieczne, aby inne funkcje językowe były praktyczne. W C ++ można mieć typy niewymienne.

struct {
    double x, y;
} p0 = { 0.0, 0.0 };
// there is no name for the type of p0
auto p1 = p0;

C ++ 11 dodał lambdy, które również są niewymienne.

auto sq = [](int x) {
    return x * x;
};
// there is no name for the type of sq

Wnioskowanie typu stanowi również podstawę szablonów.

template <class x_t>
auto sq(x_t const& x)
{
    return x * x;
}
// x_t is not known until it is inferred from an expression
sq(2); // x_t is int
sq(2.0); // x_t is double

Ale twoje pytania brzmiały: „dlaczego ja, programista, chciałbym wnioskować o rodzaju moich zmiennych, gdy czytam kod? Czy nie jest szybsze, aby ktokolwiek po prostu czytał ten typ, niż zastanawiał się, jaki on jest?”.

Wnioskowanie typu usuwa nadmiarowość. Jeśli chodzi o odczyt kodu, czasem może być szybsze i łatwiejsze mieć nadmiarowe informacje w kodzie, ale nadmiarowość może przyćmić przydatne informacje . Na przykład:

std::vector<int> v;
std::vector<int>::iterator i = v.begin();

Nie trzeba zbytnio zaznajomić się ze standardową biblioteką dla programisty C ++, aby stwierdzić, że i jest iteratorem, i = v.begin()więc deklaracja typu jawnego ma ograniczoną wartość. Swoją obecnością zasłania szczegóły, które są ważniejsze (takie jak iwskazuje na początek wektora). Dobra odpowiedź @amon stanowi jeszcze lepszy przykład gadatliwości przesłaniającej ważne szczegóły. W przeciwieństwie do tego, wnioskowanie na podstawie typu daje większe znaczenie ważnym szczegółom.

std::vector<int> v;
auto i = v.begin();

Podczas gdy czytanie kodu jest ważne, nie jest wystarczające, w pewnym momencie będziesz musiał przestać czytać i zacząć pisać nowy kod. Nadmiarowość kodu powoduje, że modyfikowanie kodu jest wolniejsze i trudniejsze. Powiedzmy, że mam następujący fragment kodu:

std::vector<int> v;
std::vector<int>::iterator i = v.begin();

W przypadku, gdy muszę zmienić typ wartości wektora, aby dwukrotnie zmienić kod na:

std::vector<double> v;
std::vector<double>::iterator i = v.begin();

W takim przypadku muszę zmodyfikować kod w dwóch miejscach. Porównaj z wnioskowaniem typu, gdy oryginalny kod to:

std::vector<int> v;
auto i = v.begin();

I zmodyfikowany kod:

std::vector<double> v;
auto i = v.begin();

Zauważ, że teraz muszę zmienić tylko jeden wiersz kodu. Ekstrapoluj to na duży program, a wnioskowanie o typach może propagować zmiany do typów znacznie szybciej niż w edytorze.

Nadmiarowość w kodzie stwarza możliwość błędów. Za każdym razem, gdy kod zależy od zachowania równoważności dwóch informacji, istnieje możliwość pomyłki. Na przykład występuje niespójność między tymi dwoma typami w tej instrukcji, co prawdopodobnie nie jest zamierzone:

int pi = 3.14159;

Redundancja utrudnia rozpoznanie intencji. W niektórych przypadkach wnioskowanie typu może być łatwiejsze do odczytania i zrozumienia, ponieważ jest prostsze niż jawna specyfikacja typu. Rozważ fragment kodu:

int y = sq(x);

W przypadku, gdy sq(x)zwraca an int, nie jest oczywiste, czy yjest to, intponieważ jest to typ zwracany, sq(x)czy dlatego, że pasuje do używanych instrukcji y. Jeśli zmienię inny kod tak, aby sq(x)nie powrócił int, z samej linii nie jest pewne, czy typ ypowinien zostać zaktualizowany. Porównaj z tym samym kodem, ale używając wnioskowania typu:

auto y = sq(x);

W tym celu intencja jest jasna, ymusi być tego samego typu, co zwrócony przez sq(x). Gdy kod zmienia typ zwracany sq(x), typ yzmian jest dopasowywany automatycznie.

W C ++ istnieje drugi powód, dla którego powyższy przykład jest prostszy w przypadku wnioskowania typu, wnioskowanie typu nie może wprowadzać niejawnej konwersji typu. Jeśli zwracany typ sq(x)nie jest int, kompilator po cichu wstawia niejawną konwersję na int. Jeśli typ zwracany sq(x)jest typem złożonym, który definiuje operator int(), to ukryte wywołanie funkcji może być dowolnie złożone.