Widziałem niektóre języki, które zmieniają się szybko (mam na myśli, że są ulepszane co roku, na przykład), a niektóre, które są poprawiane powoli.
Moje pytanie: jeśli język zmienia się szybko, czy to dobra, czy zła rzecz dla programisty? Czy programiści lubią uczyć się nowych rzeczy w języku, czy wolą trzymać się tego, co już wiedzą?
programming-languages
Simon Smith
źródło
źródło
Odpowiedzi:
Dobry
Zły
Wielu programistów lubi zaspokoić swoją ciekawość, grając z nowymi funkcjami. Nie oznacza to jednak, że nowe funkcje są zawsze odpowiednie w kodzie produkcyjnym. Jest to indywidualna decyzja, która musi wyważyć korzyści nowych funkcji w porównaniu z kosztem aktualizacji w konkretnej sytuacji.
Mogę się dobrze bawić lub czerpać przyjemność z poznawania nowych funkcji, ale pod koniec dnia naprawdę zależy mi na dostarczeniu komuś przydatnego produktu. Muszę wybrać zestaw narzędzi, który będzie wystarczająco nowoczesny, aby mieć rozsądne wsparcie i stabilność, ale nie tak starożytny, że nie mogę być wystarczająco produktywny.
źródło
Ulepszenia są świetne ... jeśli są kompatybilne wstecz .
C # robi to ładnie. Dodają różne wyrażenia lamdba, lepszą obsługę wielowątkowości, linq, ... Ale twój pięcioletni program w języku C # 2.0 będzie nadal działał ładnie bez żadnych zmian i można go łatwo uaktualnić do wersji C # 4.0 bez żadnych zmian.
Uczenie się nowych rzeczy jest świetne, jeśli pozwala ci wykonywać swoje zadania w łatwiejszy i szybszy sposób. Jeśli spędzanie godziny na nauce oznacza oszczędzanie godzin na programowaniu, jest tego warte.
źródło
Chcę regularnych ulepszeń, ale nie chcę, aby złamał bazę kodu 500 kloc i uruchomił ogromny „projekt aktualizacji”, aby kod działał tak, jak w poprzedniej wersji.
źródło
Stabilność języka jest koniecznością dla biznesu i programistów. Zmiany w języku są mile widziane, jeśli rozwiązują problemy lub wprowadzają funkcje, których brakowało we wcześniejszych wersjach, ale zmiana języków tak, aby była modna lub po prostu dlatego, że chcesz dogonić konkurenta, nie jest tak dobra.
Gdy język jest stabilny, z czasem programiści przestają koncentrować wysiłki na nauce języka, ponieważ opanowali go i zaczynają koncentrować swoje wysiłki na obsłudze biznesu tym, co wiedzą. Rezultatem jest krótszy projekt, zadowoleni użytkownicy końcowi i bardziej dumni programiści!
Zmiana wiąże się również z kosztami nauki i czasem. Nie wszyscy pracodawcy chętnie edukują programistów w zakresie nowych funkcji. Powoduje to znaczne obciążenie dla programistów, którzy muszą się szkolić - bo to nie jest banalne, kursy specjalistyczne mogą kosztować od 1500 do 3500 USD!
Ciągła zmiana może zablokować programistów w „starszym” oprogramowaniu. Weźmy przypadek programisty ASP, który nie złapał MVVM za 2 lata lub przypadek programisty Windows Forms, który nie nauczył się WPF. To zablokowanie może znacznie zaszkodzić karierze programisty.
Z czasem architektura oprogramowania w firmie staje się sałatką ogrodową. Wszelkiego rodzaju narzędzia i wersje, a projekty zaczynają robić wyłącznie aktualizację oprogramowania z jednej wersji do drugiej bez żadnych korzyści biznesowych.
źródło
Nie wydaje mi się, żeby była jakaś odpowiednia odpowiedź.
Mówiąc ogólnie, gdy język jest stosunkowo młody, jest o wiele więcej swobody, aby stosunkowo szybko dokonywać stosunkowo dużych zmian. Nie ma dużej bazy istniejącego kodu do złamania, więc ludzie są na ogół znacznie bardziej otwarci na eksperymenty.
W miarę starzenia się języka, zakładając, że staje się wystarczająco szeroki dla użytkownika, aby ktokolwiek mógł się tym naprawdę przejmować, baza istniejącego kodu zaczyna coraz mocniej ograniczać wprowadzane zmiany. Nie tylko jest więcej kodu wykorzystującego więcej funkcji, ale trudniej jest zgadnąć, jakie zmiany mogą uszkodzić kod, ale zmieniają się oczekiwania ludzi.
Załóżmy na przykład, że w Ruby i Fortran było mniej więcej tyle samo osób. Co więcej, załóżmy, że w obu przypadkach była taka sama ilość kodu. Powiedziałbym, że szanse są całkiem spore, że zmiana, która złamała dokładnie taki sam procent każdego (i w sposób, który wymagał około tej samej pracy, aby poprawić) byłaby o wiele bardziej akceptowalna dla użytkowników Ruby niż dla użytkowników Fortrana z reguły (przynajmniej zakładając, że widzieli to jako poprawę).
Myślę, że wiele zależy również od postrzegania języka przez ludzi na początku. Ludzie, którzy wybierają język, ponieważ jest to „najnowocześniejszy”, są znacznie bardziej skłonni do znoszenia poważnych zmian, które łamią wiele istniejących kodów, jeśli tylko tyle potrzeba, aby utrzymać je na najwyższym poziomie.
Kolejnym czynnikiem jest wielkość i oczekiwana długość projektów, dla których język jest przeznaczony. Język, który obsługuje stosunkowo małe projekty lub te, które znamy z góry, ma krótką oczekiwaną żywotność (np. Interfejs sieciowy) może dość często zepsuć się, ponieważ jest mało prawdopodobne, że wiele osób będzie nadal używać tej samej bazy kodu przez, powiedzmy, 10 lat w jakikolwiek sposób. Język (np. C ++ lub Java), który lepiej obsługuje większe, dłuższe projekty, które mogą zająć, powiedzmy, 5 lat, aby otrzymać pierwszą wersję, może być regularnie używany (i ciągle rozwijany) przez trzy lub cztery dekady, oczywiście wymaga wielki stabilność znacznie więcej.
źródło
Miałem faceta, który powiedział mi, że lubi jego C ++ i tak pozostanie. Nie obchodzi go ani nie interesuje się D, nie chce znać ani używać C #. Nauczył się języka Java, ponieważ MUSI to zrobić dla wielu projektów, które musiał wykonać i najwyraźniej wykonuje dobrą robotę w językach, które zna
Inny uwielbia język C # i nie zna każdego słowa kluczowego lub zna biblioteki .NET 4 (asynchroniczne i wszystkie) i nie użył abstrakcyjnych słów kluczowych ani użytych atrybutów.
Po prostu mówię, że większość ludzi NIE PIELĘGNUJ
Teraz efekty aktualizacji są zepsute (w przypadku bibliotek lub skompilowanego kodu) ludzie będą obchodzić.
źródło
Odpowiem za C # (ale ta analiza może być również zastosowana do Scali):
Ta zmiana funkcji powoduje pewne problemy, gdy zbliżasz się do „stylu” języka:
W 2011 r. C # może robić wiele różnych rzeczy i to dobrze. Niestety ma dwa różne paradygmaty (jeśli nie więcej):
Różne style sprawdzania typu
Nie zawsze jest jasne, kiedy chcesz użyć jednego lub drugiego.
źródło
Myślę, że to naprawdę zależy od języka i następujących po nim języków. Na przykład myślę, że jeśli C # i Java zaczną wyskakiwać zmiany w szybszym tempie, to zostanie zaakceptowane (o ile są one kompatybilne wstecz, jak powiedziała Carra ). Jeśli jednak język nie zyskał jeszcze trakcji i wciąż się zmienia szybko, wiem, że nie zawracałbym sobie nim głowy, ponieważ istnieje szansa, że to, czego próbuję się dziś nauczyć, będzie zupełnie inne niż to, co pojawi się za 6 miesięcy i ponieważ język jest nowy / niepopularny, nie byłoby dla mnie szkodliwe (czytaj: moja kariera), żebym go przekazał.
źródło