Mam do zrobienia aplikacje, która będzie po pierwsze obsługiwała coś w rodzaju IoT (moduły gsp i dodatkowe dane) - będzie na gniazdku po TCP odbierać i parsować dane oraz z drugiej strony ma być to kawałek CRUDa do definiowania danych i zarządzania tym, co zostanie odebrane. I teraz mam zagwozdkę co do wyboru technologii.
Python przekonuje mnie do siebie z łatwością zarządzania kodem. Na upartego można wejść i dewelopować na serwerze, który na bieżąco odbiera dane i wprowadzać poprawki. W c# proces ten jest utrudniony, bo trzeba budować i wrzucać na serwer itp itd.
Nie chcę dzielić i robić kawałka w jednym kawałka w drugim. Czy są jakieś przeciwwskazania, żeby użyć Python? Wydajność jak będzie słaba, to można na sokecie tylko obierać dane i wrzucać w kolejkę i parsować równolegle. A może w C#(.net core) jest coś ewidentnie przemawia za ta technologią (poza sztywnym typowaniem)? Dawno nie wybierałem technologi i jestem trochę zagubiony jak czerwony kapturek w lesie. Patrzę też pod to tak, że jak bym kiedyś potrzebował kogoś do tego zatrudnić, to kogo będzie lepiej zatrudnić: Pytoniarza czy .Netowca.
Z czasem w aplikacji ma się pojawić jakaś analityka, może machnie learning. Aplikacja powinna dać się odpalić na serwerze dedykowanym, jak i na jakiejś chmurze.
Co do umiejętności programowania to w obydwu technologiach czyje się podobnie.
Czy są jakieś przeciwwskazania, żeby użyć Python?
Maintenance i testowalność. Dynamiczne typowanie sprawia że pisze się szybciej, ale jak chcesz mieć pewność że coś się nie posypie to nagle robi się trudniej.
Na upartego można wejść i dewelopować na serwerze, który na bieżąco odbiera dane i wprowadzać poprawki
Moim zdaniem to raczej wada. Odpowiednie flow i proces deployowania kodu jest co prawda wolniejszy, ale jednocześnie mniej podatny na "testowanie na prodzie".
UglyMan napisał(a):
Python przekonuje mnie do siebie z łatwością zarządzania kodem. Na upartego można wejść i dewelopować na serwerze, który na bieżąco odbiera dane i wprowadzać poprawki. W c# proces ten jest utrudniony, bo trzeba budować i wrzucać na serwer itp itd.
To nie zaleta, tylko wada ;)
Zastanów się, z kim będziesz nad tym pracował, kto to będzie utrzymywał, a może kiedyś dostaniesz wrzutkę panieeee nie działa, przyjdź naprawiaj pan - i odkryjesz, że ktoś gmerał bezpośrednio na serwerze.
Jak już byś stawiał to na Pythonie, to proponuję zrobić to celowo tak, by utrudnić komuś to grzebanie i robienie sobie dowolnych poprawek. Możesz np. opakować to w dockera (nie wiem czy potrzebny, rzucam luźno propozycję), zapakować serwer pyinstallerem do execa i/lub budować wersjonowany DEB / RPM / Windowsowy instalator (nie wiem na jaki serwer chcesz to wrzucać). Jak ktoś się bardzo uprze, to i tak będzie przy tym gmerał, ale raz że mu utrudnisz - dwa, wtedy nie będzie żadnego "ale". No, także kierując się kryterium "łatwości robienia poprawek na serwerze" brałbym C#, przynajmniej po moich przygodach z N serwerów produkcyjnych i każdym z autorskimi poprawkami mistrzów Perla zza wielkiej sadzawki.
@Shalom
Dynamiczne typowanie sprawia że pisze się szybciej, ale jak chcesz mieć pewność że coś się nie posypie to nagle robi się trudniej.
Nowsze wersje Pythona (w 3.x się ciągle coś zmienia w tej kwestii, nie umiem wskazać konkretnej wersji ale strzelam między 3.4 a 3.6 i wyżej) pozwalają zrobić sobie takie bieda-typowanie z wykorzystaniem type hints. Da się nawet wymusić sprawdzanie tych typów na etapie statycznej analizy, choć w runtime ZTCP i tak nie będą sprawdzane. No chyba że sam sobie zrobisz sprawdzanie typów w runtime... co jest upierdliwe, ale się da.
@UglyMan tak właściwie to dlaczego akurat Python i C#?
superdurszlak napisał(a):
UglyMan napisał(a):
Python przekonuje mnie do siebie z łatwością zarządzania kodem. Na upartego można wejść i dewelopować na serwerze, który na bieżąco odbiera dane i wprowadzać poprawki. W c# proces ten jest utrudniony, bo trzeba budować i wrzucać na serwer itp itd.
To nie zaleta, tylko wada ;)
Zastanów się, z kim będziesz nad tym pracował, kto to będzie utrzymywał, a może kiedyś dostaniesz wrzutkę
panieeee nie działa, przyjdź naprawiaj pan- i odkryjesz, że ktoś gmerał bezpośrednio na serwerze.Jak już byś stawiał to na Pythonie, to proponuję zrobić to celowo tak, by utrudnić komuś to grzebanie i robienie sobie dowolnych poprawek. Możesz np. opakować to w dockera (nie wiem czy potrzebny, rzucam luźno propozycję), zapakować serwer pyinstallerem do execa i/lub budować wersjonowany DEB / RPM / Windowsowy instalator (nie wiem na jaki serwer chcesz to wrzucać). Jak ktoś się bardzo uprze, to i tak będzie przy tym gmerał, ale raz że mu utrudnisz - dwa, wtedy nie będzie żadnego "ale". No, także kierując się kryterium "łatwości robienia poprawek na serwerze" brałbym C#, przynajmniej po moich przygodach z N serwerów produkcyjnych i każdym z autorskimi poprawkami mistrzów Perla zza wielkiej sadzawki.
Bardziej chodziło mi o to, że etap oprogramowania obsługi protokołu komunikacyjnego z hardwarem nie będzie prosty do zrealizowania na maszynie developerskiej. Nie maiłem na myśli pisania kodu na produkcji.
@UglyMan tak właściwie to dlaczego akurat Python i C#?
Bo to trochę znam. Go, Rusty i inne Haskelle nie znam, node (js), PHP nie znam i nie chce poznać. To co mi pozostaje?
Zależy.
Jeśli masz gotowa specyfikacja, i planu za bardzo nie masz zamiaru zmieniać i bardziej byś wolał przekazać prace innym osobom to lepiej wybrać C#, ponieważ jest wtedy jest bardzo duża szansa, że otrzymasz bardziej poprawne rozwiązanie i zgodne z najlepszymi praktykami. To jest bezpieczna opcja, jeśli chodzi o sytuacje, gdzie bardziej kasę niż czas chcesz wpakować w projekt.
Natomiast jeśli specyfikacja może zmienić się w trakcie, i jeśli teraz za bardzo nie masz hajsu na ludzi, i w ogóle nie wiesz czy projekt się przyjmie, zmieni o 180' itp to lepiej wybrać Pythona, bo ten język da Ci więcej elastyczności i pozwoli Ci bardziej skupić się na produkcie, szybciej uzyskać odpowiedzi na najważniejsze pytania itp. Natomiast jak przesadzisz z dynamicznością to wiadomo będzie trudniej to utrzymać, ale jeśli będziesz stosować mypy do statycznej analizy typów, i py.test do pisania czytelnych testów to w dużym stopniu możesz uzyskać utrzymywalne rozwiązanie.
PS, ja podobny projekt robiłem do tego o którym piszesz i wtedy wybór w firmie w jakiej pracowałem padł na asyncio + django i wg mnie było lepiej niż OK.
EDIT:
Mniej więcej na tym idzie oszczędzić czas:
- stosunek lini kodu c# vs python jest na korzyść pythona (więc już jest pierwsza oszczędność)
- szybciej napiszesz testy, bo nie musisz mieć interfejsów, łatwo jest podmieniać implementację
- dużo mniej kluczowych decyzji jest po stronie pythona rzadziej myślisz o interfejsach, rzadziej potrzebujesz dziedziczenia
- biblitoki w pythonie mają czesto api bardziej pod człowieka, często dużo prostsze w użyciu niż w statycznie typowanych językach
- w pythonie jak jest błąd to sam traceback często dużo wyjaśnia
- do klepania django nie ma sobie równych, zwłaszcza jeśi chodzi o panel administracyjny
Natomiast jeśli specyfikacja może zmienić się w trakcie, i jeśli teraz za bardzo nie masz hajsu na ludzi, i w ogóle nie wiesz czy projekt się przyjmie, zmieni o 180' itp to lepiej wybrać Pythona, bo ten język da Ci więcej elastyczności i pozwoli Ci bardziej skupić się na produkcie, szybciej uzyskać odpowiedzi na najważniejsze pytania itp
A jakies argumenty ze tak wlasnie jest? Czy tylko widzimisie?
EDIT: bo chyba np. latwiej zatrudnic .netowca niz pythonowca