Pułapki w świecie rzeczywistym związane z wprowadzeniem F # do dużej bazy kodu i zespołu inżynierów [zamknięte]

Jestem CTO firmy programistycznej z dużą istniejącą bazą kodów (wszystkie C #) i sporym zespołem inżynierów. Widzę, w jaki sposób niektóre części kodu byłyby o wiele łatwiejsze do napisania w języku F #, co skutkuje szybszym czasem programowania, mniejszą liczbą błędów, łatwiejszymi równoległymi implementacjami itp., W zasadzie ogólny wzrost wydajności mojego zespołu. Widzę jednak kilka pułapek wydajności związanych z wprowadzeniem F #, a mianowicie:

1) Każdy musi nauczyć się F # i nie jest to tak trywialne jak przejście z, powiedzmy, Java na C #. Członkowie zespołu, którzy nie nauczyli się języka F #, nie będą mogli pracować nad częściami F # bazy kodu.

2) Pula programistów F # do wynajęcia na razie (grudzień 2010) nie istnieje. Przeszukaj różne bazy danych CV inżyniera oprogramowania dla „F #”, mniej niż 1% CV zawiera słowo kluczowe.

3) Wsparcie Wspólnoty w chwili obecnej (grudzień 2010 r.) Jest mniej dostępne. Możesz wyszukać w Google prawie każdy problem w C # i znaleźć kogoś, kto już go rozwiązał, a nie F #. Obsługa narzędzi innych firm (NUnit, Resharper itp.) Jest również szkicowa.

Zdaję sobie sprawę, że jest to trochę Catch-22, tj. Jeśli ludzie tacy jak ja nie używają F #, społeczność i narzędzia nigdy się nie zmaterializują itp. Ale mam firmę do prowadzenia i mogę być najnowocześniejszy, ale nie krwawiąc krawędzi.

Jakieś inne pułapki, których nie rozważam? A może ktoś zechce obalić pułapki, o których wspominałem? Myślę, że jest to ważna dyskusja i chciałbym usłyszeć twoje kontrargumenty na tym publicznym forum, które mogą wiele zrobić, aby zwiększyć przyjęcie F # przez przemysł.

Wznawia się wyszukiwanie innych języków funkcjonalnych, takich jak Scheme, Lisp lub Haskell. Wiele osób uczy się tego w szkole i ma je w swoich życiorysach; Jestem pewien, że wielu z nich nie miałoby nic przeciwko nauce F #. Mam Schemat w moim CV, chociaż nigdy nie korzystałem z niego po szkole, a praca obejmująca F # prawdopodobnie również zwróciłaby moją uwagę.

Jakieś inne pułapki, których nie rozważam?

W praktyce głównym błędem, jaki popełniam, jest zmuszanie do użycia F # w przypadku problemów, w których jest to niewłaściwe narzędzie do pracy.

A może ktoś zechce obalić pułapki, o których wspominałem?

Wszystkie są oczywiście w pewnym stopniu uzasadnione, ale zapytałbym do jakiego stopnia.

Na przykład mówisz, że każdy musiałby nauczyć się języka F #, aby pracować nad kodem F #. Chociaż to prawda, w praktyce nie jest to wielka sprawa. Nauka F # nie jest bardziej znacząca niż nauka WPF, Silverlight lub TPL. Uczę około 30 programistów, jak używać F # dla klienta w Londynie, a kilkanaście pracowało w pełnym wymiarze godzin nad kodem F # już po kilku tygodniach i właśnie wysłali swój pierwszy produkt (na czas i zgodnie z budżetem! ) napisane prawie w całości w języku F # już po kilku miesiącach. W rzeczywistości mieli więcej problemów technicznych z Silverlight niż F # i stwierdzili, że wsparcie techniczne dla Silverlight było znacznie gorsze niż dla F #.

Odwołujesz się do stosunkowo niewielkiej puli dostępnych programistów F #, ale znowu, biorąc pod uwagę, jak łatwo jest zdobyć F #, nie sądzę, że jest to poważny problem. Wątpię, czy będziesz musiał zatrudnić wielu, jeśli w ogóle. Mój klient ma dwóch facetów F # dla ponad 100 programistów, a naszym zadaniem jest inicjowanie i nadzorowanie użycia F #.

Twoja trzecia i ostatnia kwestia dotyczy mniej wsparcia społeczności, Googling dla rozwiązań C # w porównaniu z F # i obsługi narzędzi zewnętrznych. Znów nie znalazłem w praktyce problemów. Wysłałem e-mailem fsbugs z komentarzem na temat jednostek miary w F # i otrzymałem odpowiedź w ciągu 24 godzin od badacza, który go wymyślił, ze szczegółowym wyjaśnieniem, dlaczego moja interpretacja była błędna i dlaczego działa tak, jak robi. Nigdy nie dostałem tego od Andersa Hejlsberga ;-). Cały czas szukam rozwiązań w Google i znajduję je w C #, VB, a nawet IronPython, ale po 3 latach korzystania z branży F # mogę sobie przypomnieć tylko jeden przypadek, w którym tłumaczenie rozwiązania na F # nie było banalne. W rzeczywistości niedawno przekonwertowałem próbkę C # serializatora danych z MSDN na F # i była ona 5 razy krótsza. Na koniec wspomniałeś o wsparciu F # w narzędziach takich jak NUnit, kiedy „ używam NUnit od F # bez problemu przez jakiś czas. Są to narzędzia .NET, a nie narzędzia C #.

Studium przypadku : Mój obecny klient nie tylko używa NUnit do testowania jednostkowego, ale zbudował TickSpec w F # na NUnit jako technicznie lepszą alternatywę dla SpecFlow dla BDD. Autor wskazał mi, że TickSpec to niewielki ułamek wielkości SpecFlow i zapewnia więcej funkcji. Co więcej, kilku programistów pracujących bez wcześniejszego doświadczenia w języku F # (i uważam, że nie było wcześniejszego doświadczenia w programowaniu funkcjonalnym) podniosło go i zaczęło bez problemu używać go w niepowiązanych projektach, ponieważ F # + TickSpec ułatwia rozwiązywanie ich problemy.

FWIW, dałem mojemu klientowi bezpłatną subskrypcję strony na nasz dziennik F # .NET Journal, który poszedł dobrze, gdy wielu programistów uczy się F #.

HTH!

Jak rozpoznasz w pierwszym punkcie, twoi programiści, którzy nie znają F #, nie mogą pracować na części F # twojej bazy kodu. Jednak nie musisz przepisywać całej bazy kodu w F #, aby czerpać korzyści z korzystania z niej - po prostu przepisz części, w których zobaczysz największą korzyść. Fakt, że F # naprawdę dobrze współpracuje z C #, powinien względnie łatwo wykroić niektóre części i tworzyć z nich zespoły F #.

Jeśli mielibyście inżynierów pracujących nad tradycyjną aplikacją trójwarstwową, prawdopodobnie nie nalegalibyście, aby wszyscy musieli mieć głęboką znajomość SQL, HTML, JavaScript, CSS itp. Zamiast tego mielibyście oczywiście specjalistów w różnych częściach aplikacji. Dlatego nie sądzę, że dodanie nowego języka dla jednej części aplikacji powinno być zbyt dużą przeszkodą. Ponadto możesz użyć standardów kodowania i innych praktyk, aby upewnić się, że kod F # jest czytelny nawet dla inżynierów bez głębokiego tła F #.

Pułapki związane z dodawaniem języka F # do używanych języków obejmują pułapki związane z wprowadzaniem nowych technologii. Niezależnie od korzyści, jeśli część Twojego zespołu nie chce lub nie jest wystarczająco elastyczna, aby się uczyć, nie będzie w stanie pracować nad projektami F #. Niemniej jednak, jeśli pozwolisz dinozaurom w swoim zespole uniemożliwić przyjęcie nowych technologii, Twoja firma będzie skazana na niepowodzenie.

Jedyne pułapki, których osobiście doświadczyłem, to:

1. Trudności podczas debugowania. Podążanie za procesem wykonywania programu opartego na wyrażeniach w debuggerze przeznaczonym dla języków opartych na instrukcjach może być trudne.

2. Frustrująca inteligencja. Automatyczne uzupełnianie przestaje działać dokładnie wtedy, gdy jest to potrzebne. Microsoft musi pracować nad tym, aby parser w tle był bardziej odporny na błędy.

3. Składnia wrażliwa na wcięcia utrudnia kopiowanie-wklejanie lub formatowanie kodu.

4. Brak refaktoryzacji.

5. Niektóre z istniejących wygodnych rozszerzeń VS dla F # (składanie kodu, kolorowanie głębi) są nieco wolne, co sprawia, że ​​pisanie na klawiaturze jest nieco frustrujące.

Moim zdaniem żadna z tych kwestii nie jest przeszkodą w występach i na razie mogę z nimi żyć. Narzędzia są łatwiejsze do ulepszenia i naprawy niż języki.

Twoje obawy, że zatrudnienie nowych programistów zdolnych do pisania w języku F # byłoby trudne, są dość powszechne, ale moim zdaniem nieuzasadnione. Jeśli miałbyś napisać wytyczne dotyczące kodowania, czy odradzałbyś lub zabronił ci jednej z następujących funkcji w C #: yield returnLINQ do obiektów, lambdas, nadchodzących async?

Jeśli uważasz, że te funkcje pomagają pisać lepszy kod, nie ma powodu, aby powstrzymywać się od F #. Język obsługuje te funkcje w płynny i przemyślany sposób, czego C # nie może naprawdę zrobić ze względu na swoją spuściznę.

Jeśli twój zespół jest wystarczająco inteligentny, aby zrozumieć koncepcje kryjące się za funkcjami, o których wspomniałem, mają wszystko, czego potrzebują, aby być doskonałymi programistami w języku F #. To samo dotyczy przyszłych rekrutów: czy zatrudniłbyś kogoś, kto nie jest w stanie lub nie chce korzystać z funkcji wprowadzonych po C # 1.0?

Rozważałem tę dokładną sytuację.

Oto co planuję dla mojego zespołu:

• Mieszaj C # z F #, można to zrobić za pomocą C # dla większości kodu bazowego. Tam, gdzie wymagane jest intensywne przetwarzanie danych , zapisz powiązane funkcje w F # i umieść je w bibliotece dll lub odwołaj się do niego. Przykład tutaj

• Powoli ponownie uwzględnij istniejącą bazę kodu w powyższy sposób.

• Nie cały kod musi działać.

• Poproś swój zespół o naukę podstaw Haskell, LISP w weekendy .

• Poproś ich, aby nauczyli się języka F #, próbując rozwiązać zagadki z projektu Euler (bardzo mi to pomogło, gdy uczyłem się języka F #). Znowu powinno to być zrobione w ciągu weekendu lub w czasie pracy, jeśli chcesz wyznaczyć dzień na „szkolenie”.

1) Nauka języka funkcjonalnego zwiększy ogólną zdolność programisty, jednak dotyczy to tylko tych, którzy chcą się uczyć i doskonalić. Nie każdy programista chce być lepszy, nie chce też zmieniać środowiska pracy (znać swój zespół).

2) Nie mogę się z tym kłócić. Będziesz musiał zapłacić za sześciomiesięczną krzywą uczenia się dowolnego nowego języka, jednak znajomość bibliotek .net eliminuje dodatkowe lata wymagane do nauki nowych bibliotek.

3) Wsparcie społeczności, choć mniejsze niż C #, ma całkiem sporo wysoko wykwalifikowanych aktywnych programistów F # publikujących w Internecie. Nie zapominaj, że większość języków obsługuje biblioteki i istnieje doskonałe wsparcie dla platformy .NET.

Tysiąc funtowy goryl tutaj to zarządzanie ryzykiem. „Mogę być nowatorski, ale nie krwawiący”. Twierdziłbym, że F # nie krwawi. Został wydany z VS2010 i jest bezpośrednio obsługiwany przez Microsoft. Nowością jest „beta” i zrzeczenie się odpowiedzialności od Microsoft, które mówi coś o tym, że nie jestem za nic odpowiedzialny.

Praktycznie brakuje obsługi IntelliSense - do tego stopnia, że ​​wzrost wydajności wnioskowania typu jest prześcigany przez mniej zaawansowane autouzupełnianie dostępne w C #.

Komunikaty o błędach spowodowane błędnymi wnioskami o typie również wymagają dłuższej naprawy dla początkujących (i często dla użytkowników pośrednich, takich jak ja), po prostu dlatego, że masz mniejszą skłonność do dostarczania adnotacji typu niż w języku takim jak C #.

OOP brakuje również w zaskakujący sposób w F #; na przykład nie ma obsługi zagnieżdżonych typów / klas. Musisz być ostrożny przy przenoszeniu kodu, ponieważ jest kilka rzeczy, które możesz zrobić w C #, których nie możesz zrobić w F #, niestety.

Wreszcie, zarówno wielkość, jak i jakość społeczności F # jest trochę rozczarowująca. Wiele informacji w języku F # dostępnych w Internecie dotyczy albo starych wersji, albo po prostu niezbyt dobrych - albo nie idiomatycznych, słabej wydajności lub całkowicie błędnych. Są też ludzie, którzy pobierają ogromne pieniądze za biuletyny, które są w dużej mierze tylko istniejącymi skrótami informacji.

Sam używam C # do projektów pracy i F # do własnych rzeczy. Mimo że uwielbiam F #, niestety trudno jest przewidzieć, jak / kiedy wszystko może się rozpaść.

Głównym problemem jest zawsze łatwość konserwacji.

Chciałbym kodować w Schemacie, ale następny opiekun prawdopodobnie chciałby mnie dopaść i torturować.

Powiedziałbym, że pierwszą rzeczą, którą musisz zrobić, to zapytać członków zespołu, co sądzą o wprowadzeniu F #. Jeśli podoba im się ten pomysł, wszystko pójdzie dużo płynniej, a jeśli nie.