Zadania IT: skrypt F # kontra Powershell

Question

Wiem, że Powershell jest ogólnie uważany za język zarządzania IT dla okien, ale dlaczego/kiedy miałbyś wybrać F # zamiast tego, który jest mocno napisany i "intellisensed"?

Answer 1

Wybrałabym F #, gdy był lepszy dla firmy, dla której pracowałem, dla zespołu, który będzie z niej korzystać, i dla zadania, które jest pod ręką. W przeciwnym razie wybrałbym coś innego.

nie mogę być bardziej szczegółowe niż bez więcej szczegółów, ale mogę zaproponować kilka pytań należy zadać:

1. czym polega problem masz rozwiązanie?
2. W jakim języku łatwiej jest wyrazić rozwiązanie problemu?
3. Czy są już samymi programiści F # (np. Biorąc pod uwagę krzywą uczenia się)?
4. Czy osoby, które utrzymują ten kod, będą administratorami (którzy zazwyczaj są dość obeznani z Powershell, & niezupełnie znający F #)?

Podobna podpowiedź: nie dopuść do rozwinięcia się wielu języków w kodzie produkcyjnym i infrastrukturze.

Za wszelką cenę poeksperymentuj, aby znaleźć najlepszy język, aby rozwiązać problem, który masz, ale jeśli za pięć lat zauważysz, że ktoś napisał kluczowy komponent twojego rozwiązania w języku, który nie jest już zrozumiany przez nikogo w firmie możesz mieć poważny problem na twoich rękach.

Moja osobista zasada (oczywiście są wyjątki) polega na tym, że projekt powinien zawierać język podstawowy i język skryptowy, aby je wszystkie razem przechowywać, &, że te języki powinny zostać wybrane jako pierwsze w celu dopasowania do domeny problemu, oraz po drugie, aby zmaksymalizować biegłość w zespole. "Języki dla zwierząt domowych" powinny być zniekształcone w kodzie produkcyjnym lub infrastrukturze .

Answer 2

To zależy od twojego problemu i od tego, kto będzie obsługiwał skrypty.

PowerShell jest bardzo silny w obszarach administracyjnych (praca z plikami, katalogiem aktywnym, csv/xml, komputerami itp.), Ale jego możliwości programistyczne są dość ograniczone (na przykład w przypadku generycznych). Nawlekanie w PowerShell nie jest tak proste, jak mogłoby być. Ale nikt nie oczekuje od administratorów, że będą używać wątków. Zamiast tego istnieją zadania w tle, które satysfakcjonują potrzeby administratora.

Z drugiej strony, F # jest prawdziwym językiem programowania, co oznacza, że ​​jest dość niski i dlatego jest pełny (w porównaniu do PowerShell). Niektóre zadania napisane w PowerShell są jednolinijkowe, podczas gdy w F # napisałeś dużo kodu. Poza tym - w jaki sposób uzyskałbyś polecenie uruchamiania na zdalnych komputerach (Invoke-Command -computer myserver ...)?

Jak widać, zależy to od twojego problemu.
Bardzo ważne jest również, kto będzie obsługiwał skrypty. Możesz być na wakacjach, a twoi koledzy będą musieli edytować skrypty. Oba języki potrzebują czasu na naukę. IMHO łatwiej się nauczyć PowerShell; myślenie w stylu funkcjonalnym musi pochylić głowę.

Answer 3

To chyba zły pomysł, aby w tym momencie pisać skrypty w języku F #, jeśli mogą być potrzebne komuś innemu niż sobie ...

1. Kadra ludzi mówiących F # jest bardzo mała, więc tworzysz skrypty, które bardzo niewiele osób może czytać lub edytować.
2. Plik wykonywalny fsi nie jest dostarczany z .Net Framework, ani nie jest częścią pakietu redystrybucyjnego środowiska wykonawczego F # (o ile wiem). Oznacza to, że skrypty mogą być wykonywane tylko wtedy, gdy zostały zainstalowane Visual Studio z narzędziami F #.

oczywistym wyjątkiem, oczywiście, jeśli jesteś programistą pracuje nad projektem, gdzie F # jest językiem podstawowym, ponieważ będzie oznaczać, że każdy się liczy będzie w stanie uruchomić i edytować twoje skrypty.

Jednak muszę powiedzieć, że myślę, że nawet w tej idealnej/wyjątkowym przypadku, będzie to prawdopodobnie więcej pracy używać F # jeśli zadanie skryptów obejmuje zadania, dla których nie są wstępnie istniejące cmdlet w PowerShell (tj. zadania systemu plików, rejestr, utrzymanie bazy danych, katalog aktywny, wymiana, lista jest długa). Oczywiście nadal możesz to zrobić, jeśli używasz tych skryptów jako okazji do nauki języka, ale pamiętaj o punktach 1 & 2 ;-)