Czy algorytm jest ważniejszy niż język programowania?

35

Podczas bieżącego (2013) konkursu Google Code Jam wystąpił problem polegający na tym, że C ++ i Java mieli ponad 200 linii kodu w porównaniu do osób w Pythonie, które rozwiązały ten sam problem przy użyciu tylko 40 linii kodu.

Python nie jest bezpośrednio porównywalny z C ++ i Javą, ale różnica w gadatliwości, która, jak sądzę, może mieć wpływ na wydajność algorytmu.

Jak ważna jest znajomość właściwego algorytmu w porównaniu do wyboru języka? Czy doskonale zaimplementowany program Python można lepiej zaimplementować w C ++ lub Javie (przy użyciu tego samego algorytmu) i czy ma to jakiś związek z naturalną gadatliwością niektórych języków programowania?

superpacemaryny
źródło
16
Powiedziano (i wierzę w to), że język programowania, w którym pracujesz, ma wpływ na sposób, w jaki myślisz o problemie. Oznaczałoby to, że bardzo różne języki programowania mogą być dostosowane do różnych klas problemów.
Joris Timmermans
1
Wiele z tego całkowicie zależy od skali, nad którą pracujesz poza LOC. Niektóre języki po prostu nie obsługują prędkości ani współbieżności. Algorytmy są ważne, ale czasami jeśli język x jest y razy wolniejszy niż język z, po prostu nie można użyć x niezależnie od gadatliwości.
Przypon
Dla przypomnienia, jedyną rzeczą, której nauczyłem się w szkole, jest to, że każdy ma błąd w liniach kodu, który pozostaje stały, niezależnie od użytego kodu. Tak więc, jeśli język, który pozwala ci to zrobić w mniejszej liczbie wierszy kodu, powoduje mniej błędów, możesz szybciej wprowadzić go na rynek i mieć mniejsze szanse na pojawienie się błędu, gdy użytkownik go używa. Tak więc, moim zdaniem, wybrałbym najlepszy język dla pracy, którą wszyscy inni w firmie wiedzą, że jest wymagana do pracy nad tym projektem.
Travis Pessetto,
5
@Travis: „wada na wskaźnik SLOC pozostaje stała bez względu na język” po prostu nie jest prawdą. Zobacz odpowiedź Johna.
Ben Voigt,
Teraz myślisz o wzięciu udziału w następnym konkursie, używając F # jako języka!
code4life

Odpowiedzi:

73

Oczywiście, jeśli rozważymy to pytanie w kontekście czegoś takiego jak Google Code Jam, wówczas myślenie algorytmiczne jest wyraźnie ważniejsze przy rozwiązywaniu problemów algorytmicznych.

W życiu codziennym należy jednak wziąć pod uwagę około milion innych czynników, co sprawia, że ​​pytanie jest znacznie mniej czarne niż białe.

Tylko kontrprzykład: jeśli potrzebujesz 200 kolejnych linii w Javie, ale wszyscy w Twojej firmie znają Javę, to nie jest wielka sprawa. Gdybyś mógł napisać go w 5 wierszach Pythona lub w innym języku, ale byłbyś jedynym w firmie, który znałby ten język - to wielka sprawa. Tak wielka sprawa, że ​​nawet nie będziesz mógł tego robić i zamiast tego będziesz musiał napisać ją w Javie.

Z punktu widzenia Craftman za, zawsze staramy się podchodzić z odpowiednim narzędziem do pracy, ale słowo prawo w nie jest tak trudne, że można łatwo dostać to źle.

Przeciwnie, stwierdziłem, że algorytmiczne myślenie w firmach jest prawie nieobecne. Tylko nieliczne wybrane osoby go posiadają, podczas gdy przeciętny Joe często ma problemy z oszacowaniem złożoności pętli, wyszukiwań itp.

Jeśli chodzi o konkursy algorytmiczne, moje osobiste doświadczenia z kilkuletniej rywalizacji wyraźnie wskazują, że powinieneś trzymać się jednego języka. Szybkość jest głównym czynnikiem i po prostu nie możesz sobie pozwolić na marnowanie czasu na swoje narzędzia, kiedy powinieneś poświęcić je na rozwiązywanie problemów w wyznaczonym terminie. Weź również pod uwagę, że pisanie 200 wierszy kodu Java bez zastanowienia jest wciąż znacznie szybsze niż ręczne tworzenie 50 wierszy skomplikowanego kodu python wymagającego dużo myślenia, ale oba rozwiązują mniej więcej ten sam problem.

No i na koniec upewnij się, że rozumiesz główne różnice między algorytmicznym kodem konkurencji a kodem produkcyjnym firmy. Widziałem fantastyczne kodery algorytmiczne, które napisały okropny kod, którego nigdy nie zaakceptowałbym w produkcie.

Szczery
źródło
1
+ 1 za „milion innych czynników, które należy wziąć pod uwagę”
oz.
1
Dodam do tego, że jeśli próbujesz rozwiązać problem funkcjonalny, to na litość boską, użyj funkcjonalnego języka! Dlatego twierdzę, że naprawdę powinieneś trzymać jeden język na jeden główny paradygmat programowania.
Martijn Verburg
6
+1 za ostatnie zdanie.
Shivan Dragon,
4
+1 Linie kodu same w sobie są straszną miarą. Musimy mierzyć łatwość konserwacji , a nie wiersze kodu. 200 linii kodu typu może potencjalnie być łatwiejsze w utrzymaniu niż 50 linii Pythona.
Phil
2
@Phil: A 200 wierszy języka Python może potencjalnie być łatwiejsze w utrzymaniu niż 50 wierszy kodu typu. Nigdy nie widziałem takiej przewagi przejrzystości w językach bezpiecznych dla typu, przy założeniu dobrze napisanego kodu.
David Thornley,
17

Twierdziłbym, że nawet poza zawodami myślenie algorytmiczne jest ważniejsze niż znajomość każdej sztuczki dla określonego języka.

Oczywiście chcesz jak najlepiej znać język, z którym pracujesz, ale języki przychodzą i odchodzą, a umiejętność abstrakcyjnego myślenia w zakresie algorytmów jest umiejętnością bardzo łatwą do przenoszenia.

Przykład: jeśli dobrze pamiętam, jakiś czas temu tutaj był programista, w którym ktoś narzekał na niepowodzenie FizzBuzz w wywiadzie i obwiniał go za brak wiedzy o operatorze modulo Javy. Ten wniosek jest błędny - brak wiedzy na temat działania modulo sprawił, że nie był w stanie myśleć algorytmicznie o problemie i rozwiązać go, nawet przy braku dedykowanego operatora modulo. Idąc dalej: Java ma klasę drzewa - co jeśli w przyszłości będziesz musiał pracować z językiem, który nie implementuje tej klasy? Ponownie umiejętność myślenia o problemie przebija szczegóły specyficzne dla języka.

Przyznaję, że przykłady są uproszczone, ale pomagają przybliżyć sprawę.

ACEG
źródło
14

Język ma znaczenie.

DARPA i marynarka wojenna USA przeprowadziły eksperyment strzelaninowy prawie 20 lat temu. Zwycięzcą uciekającego ciemnego konia został Haskell. Zarówno Ada, jak i C ++ były reprezentowane; Java nie była.

Mniej więcej w tym samym czasie Pratt & Whitney przeprowadził badanie eksploracji danych dotyczące projektów sterowników silników odrzutowych, analizując dane karty czasu i narzędzia do śledzenia błędów. Odkryli, że Ada podwoiła wydajność programisty i gęstość defektów w każdym innym używanym języku.

Atari używał FORTH do opracowywania gier wideo, a fakt, że korzystali z FORTH, był uważany za wyjątkowo zastrzeżony.

Komentarze Paula Grahama dotyczące korzystania z LISP są dobrze znane. Erann GAT za komentarze na LISP w JPL są równie przekonujące, choć nie tak dobrze znane.

Boeing 777 awioniki oprogramowanie jest dość dużo wszystko Ada. Ich doświadczenie było bardzo dobre, chociaż jeden główny podwykonawca musiał zacząć od nowa w połowie strumienia.

Język ma znaczenie.

John R. Strohm
źródło
Oczywiście java została wydana po tym eksperymencie, z którym się łączysz.
toasted_flakes
artykuł ukazał się w 1994 roku. Pierwszą publiczną wersją Javy był 1995.
Alessandro Teruzzi
Nie chodzi o to, że Twój ulubiony język był reprezentowany lub nie był reprezentowany w jednym konkretnym eksperymencie. Chodzi o to, że język ma znaczenie. Było wiele anegdotycznych badań, które pokazują to dość jednoznacznie. Warto również zauważyć, że pomimo tego, że zostały głównie odrzucone przez amerykańskich programistów, Ada jest nadal intensywnie używana w Europie, szczególnie w systemach o wysokiej niezawodności, i nadal jest stosowana w niektórych systemach polowych w USA.
John R. Strohm
7

Kilka punktów:

  • Najwyższe pozycje to zwykle C ++ / C / Java, niezależnie od tego, ile wierszy kodu różni się między tym a innym językiem. Może to być bardziej związane z tym, że najlepsi koderzy wybierają te języki spośród innych, prawdopodobnie ze względu na ich szybkość.
    Niestety nie można łatwo zobaczyć języka programowania w Google Code Jam, ale pobrałem kilka najlepszych i, o ile pamiętam, są to głównie C / C ++. TopCoder (popularny serwis hostingowy internetowych konkursów programistycznych) ma w większości podobne wyniki.

  • Ponieważ mają dość niski poziom, jestem pewien, że nie pokonasz C / C ++ pod względem surowego czasu działania (a Java nie pozostawia zbyt wiele w tyle). Z mojego doświadczenia wynika, że ​​języki pisane dynamicznie są zwykle wolniejsze niż języki pisane statycznie. Optymalne rozwiązanie może nawet nie być wystarczająco szybkie w niektórych językach, ale nie powinna to być ogólna zasada.

  • Właściwy algorytm jest niezbędny. Jeśli od samego początku wiedziałeś, jak rozwiązać wszystkie problemy (bardzo szczegółowo), i jesteś dobrym, szybkim programistą, najprawdopodobniej wygrasz, bez względu na język, w którym kodujesz (przy założeniu optymalnego rozwiązania w tym języku) jest wystarczająco szybki).

  • Prosta liczba linii nie jest taka wielka. Gdy zdobędziesz wystarczające doświadczenie w programowaniu, będziesz wiedział, że możesz poświęcić 10 minut na programowanie 10 linii lub 200 linii, wszystko zależy od stopnia złożoności linii. Ponadto, jeśli kodujesz podobny kod setki razy, będziesz mógł to zrobić dość szybko. Nie wspominając już o wszystkich makrach, których często używają najlepsi kodery C / C ++ w celu optymalizacji swojego czasu kodowania.

  • Frank ma rację - (poza konkursami programistycznymi) nie możesz zajmować się kodowaniem w Pythonie dla swojej firmy, jeśli cała baza kodu jest w C lub cokolwiek innego, musisz dostosować się do ich języka.

  • Przełączanie między językami jest dość łatwe, nie jest łatwo zbudować lata wiedzy na temat algorytmicznego myślenia. Jestem skłonny założyć się, że prawie każdy doskonały programista może przełączyć się na inny (nieco podobny) język w, powiedzmy, tygodniu. Być może on / ona nie będzie wystarczająco dobry, aby wygrać konkursy programistyczne w tym języku (daj mu kolejne 2 tygodnie), ale będzie miał podstawy.

Dukeling
źródło
Fałsz: Pobieranie kilku rozwiązań z niektórych stron z konkursami na kod jest ostatecznym badaniem naukowym wystarczającym do stwierdzenia, że ​​na pewno wiesz, jak wyglądają najwyższe pozycje.
Lie Ryan,
@LieRyan To prawda, ale udział w kilkudziesięciu konkursach programistycznych (jak mam) na (prawdopodobnie) najpopularniejszej stronie (TopCoder) i zawsze widzenie większości czołowych pozycji jako C / C ++ / Java jest dość znaczące. Powiedziałem też, że „zwykle” nie „zawsze” są.
Dukeling,
nie zgadzają się, że „Prosta liczba linii nie jest aż tak wielkim problemem”. kod jest wrogiem
jk.
6
@jk. Czy powinienem wyróżnić „takie”? To ma znaczenie, ale to nie jest alfa i omega. Wolisz kilka mniej wierszy niż czytelność? Na pewno nie. Każdego dnia wezmę kilka prostych instrukcji if do bardzo mylącego, nieczytelnego, przesuwającego bity, mnożącego, dzielącego, dodającego, odejmującego, XORing, ANDing, wyrażenia warunkowego. Być może nie o tym mówiłeś, ale czasami sprowadza się to do zmniejszenia liczby linii. Mówiłem bardziej o implementacji czegoś złożonego w kilku liniach lub czegoś prostego w wielu liniach; ten drugi często zajmuje mniej czasu.
Dukeling,
5

Czy ta sama logika może być lepiej zaimplementowana w C ++? Oczywiście, że tak, jeśli przez to lepiej rozumiesz szybszą i bardziej wydajną pamięć. Problem polega na tym, że wysiłek wymagany do tego celu jest znacznie wyższy. Co więcej, teoretycznie nadal możesz przejść na niższy poziom i wdrożyć go w czystym C lub nawet ASM, co potrwa jeszcze dłużej, ale możesz mieć jeszcze bardziej zoptymalizowany kod.

Oczywiście w przypadku zawodów takich jak Code Jam czy TopCoder nie jest to biggie, ponieważ ma tylko 40 linii w porównaniu do 200 linii. Z drugiej strony w tego rodzaju zawodach najważniejsze jest złożoność algorytmu w czasie / przestrzeni. Podczas gdy w rzeczywistych aplikacjach, YMMV, w tego rodzaju konkursach algorytm O (n) napisany w najwolniejszym języku zawsze pokonuje O (n²) napisany w najszybszych językach. Zwłaszcza, że ​​będzie wiele testów, które są najgorszym scenariuszem.

Ale pomijając konkursy, jeśli mówimy o dużych projektach z prawdziwego życia, to nie jest to już 40 linii w porównaniu do 200 linii. W dużych projektach ogromna baza kodu zaczyna stanowić problem. W którym momencie dojdziesz do:

C ++ vs Python?

wprowadź opis zdjęcia tutaj

Czysty Python działa wolno. Dlatego standardem interpreter Pythona (CPython) jest napisany w C. Praktycznie wszystkie z wbudowanych funkcji pisanych jako wysoce zoptymalizowanej C. Python również mogą być łatwo wykorzystane w połączeniu z bibliotekami C (poprzez ctypes lub natywnych modułów CPython ) i C bibliotek ++ przez Boost :: Python . W ten sposób możesz napisać logikę wysokiego poziomu w języku Python, który jest elastyczny, umożliwia szybkie prototypowanie i adaptację (co oznacza, że ​​możesz poświęcić więcej czasu na ulepszanie i ulepszanie algorytmu). OTOH, możesz pisać funkcje biblioteki niższego poziomu w module C lub C ++. Świetnym przykładem takiego podejścia jest SciPy, która jest biblioteką Python, ale pod maską wykorzystuje wysoce zoptymalizowane biblioteki numeryczne, takie jak ATLAS, LAPACK, Intels MKL lub ACML AMD.

vartec
źródło
To, co piszesz, tylko ociera powierzchnię. Zakładasz pojęcie „lepsze”, że nie wszyscy się nim dzielą. Jakość jest zawsze kwestią dopasowania do celów. Programowanie w C ++ nie zawsze jest dobre dla każdego celu.
reinierpost
1
@reinierpost: dlatego pisałem o znacznie większym wysiłku. W przypadkach, w których wspominasz, C ++ nie jest dobrze dopasowane, ale nie dlatego, że nie można tego zrobić. To nie jest dobre dopasowanie, ponieważ zajmie zbyt dużo zasobów dla programistów.
vartec
Co więcej, w tym przypadku po prostu nie jest lepiej.
reinierpost
2
i w rzeczywistości dzieje się tak w wielu branżach, na przykład gry zawierają dużo kodu Lua, który skleja kod C ++ zarówno pod względem wydajności, jak i wydajności.
gbjbaanb
4

Moim zdaniem to, co ludzie potocznie uważają za „języki programowania”, to tak naprawdę trzy osobne rzeczy:

  1. Typ języka i składnia
  2. IDE języka
  3. Dostępne biblioteki dla języka

Na przykład, gdy ktoś porusza C # w dyskusji, możesz myśleć, że mówi on o składni języka (1), ale jest 95% pewności, że dyskusja będzie dotyczyła frameworka .Net (3). Jeśli nie projektujesz nowego języka, trudno jest izolować (1) i ignorować (2) i (3). Wynika to z faktu, że IDE i standardowa biblioteka to „czynniki komfortu”, które bezpośrednio wpływają na korzystanie z określonego narzędzia.

W ostatnich latach również uczestniczyłem w Google Code Jam. Po raz pierwszy zdecydowałem się na C ++, ponieważ ma ładne wsparcie dla odczytu danych wejściowych. Na przykład odczyt trzech liczb całkowitych ze standardowego wejścia w C ++ wygląda następująco:

int n, h, w;
cin >> n >> h >> w;

Podczas gdy w C # to samo wyglądałoby tak:

int n, h, w;
string[] tokens = Console.ReadLine().Split(' ');
n = int.Parse(tokens[0]);
h = int.Parse(tokens[1]);
w = int.Parse(tokens[2]);

To o wiele więcej kosztów ogólnych dla prostej funkcjonalności. Sprawa staje się jeszcze bardziej skomplikowana w języku C # przy wprowadzaniu multilinii. Może po prostu wtedy nie wymyśliłem lepszego sposobu. W każdym razie nie udało mi się zaliczyć pierwszej rundy, ponieważ miałem błąd, którego nie mogłem naprawić przed końcem rundy. Jak na ironię metoda odczytu danych wejściowych zaciemniła błąd. Problem był prosty, wejście zawierało liczbę, która była zbyt duża dla 32-bitowej liczby całkowitej. W C # int.Parse(string)zgłasza wyjątek, ale w C ++ strumień wejściowy do pliku ustawia pewną flagę błędu i nie powiedzie się po cichu, powodując, że niczego nie podejrzewający programista nie będzie wiedział o problemie.

Oba przykłady pokazują, w jaki sposób biblioteka była używana, a nie składnia języka. Pierwszy pokazuje gadatliwość, a drugi wiarygodność. Wiele bibliotek jest przeniesionych do wielu języków, a niektóre języki mogą korzystać z bibliotek, które nie zostały specjalnie dla nich zbudowane (patrz odpowiedź @ vartec na temat Pythona z bibliotekami C).

Podsumowując, znajomość właściwego algorytmu pomaga. W konkursach kodowania ma to kluczowe znaczenie, szczególnie gdy zasoby takie jak czas wykonania i pamięć są celowo ograniczone. Przy tworzeniu aplikacji jest to mile widziane, ale generalnie nie jest kluczowe. Utrzymanie jest tam ważniejsze. Można to osiągnąć poprzez zastosowanie prawidłowych wzorców projektowych, dobrą architekturę, czytelny kod i odpowiednią dokumentację, a wszystkie te metody w dużym stopniu zależą od bibliotek wewnętrznych i zewnętrznych. Dlatego uważam, że ważniejsze jest, aby wiedzieć, jakie koła są już wynalezione i jak pasują, a następnie jak zrobić własne.

Cesarz Orionii
źródło
1
Przygotowanie jest ważne, jeśli to możliwe. Dzięki Google Code Jam mam małą bibliotekę, która odczytuje dane wejściowe i wyświetla dane wyjściowe tak, jak tego chcą, i dołączam ten kod do mojego zgłoszenia.
Mark Hurd
Za drugim razem zrobiłem coś podobnego, ale jako szablon projektu. Tworzy plik źródłowy z klasą wejściową poniżej Maini kilkoma elementami w Mainmetodzie (instancja mojej klasy wejściowej oraz strumień wyjściowy i pętla spraw).
Cesarz Orionii
Nie pamiętam, kiedy ostatni raz czytałem ze standardowego. Daj mi plik, który mogę umieścić w parserze JSON.
gnasher729
2

Jeśli chcesz brać udział w konkursach programowania czasowego, powinieneś nauczyć się najbardziej ekspresyjnego języka dozwolonego w konkursie. Perl byłby prawdopodobnie najlepszy, a za nim Ruby lub Python. Nadal będziesz potrzebować dobrego zaplecza z algorytmami, ale przynajmniej nie utkniesz w pisaniu czegoś takiego

Integer prev = b.get(k)
if (prev == null) prev = 0
Integer v = a.get(k);
if (v == null) v = 0;
b.put(prev + v);

zamiast

b[k] += a[k]

Nie martw się o naukę kilku bibliotek. Wszystkie są bardzo podobne, a dokumentacja jest dostępna online. Znajomość języków bardziej ekspresyjnych sprawi, że będziesz lepszym (ale być może sfrustrowanym) programistą w mniej ekspresyjnych językach. Przeciwnie nie jest prawdą.

NB

Różnica między 200 liniami kodu a 40 liniami kodu jest ogromna, a nawet większa, gdy jest to różnica między programem 200 000 linii a programem 40 000 linii. To jest różnica między pięcioosobowym zespołem plus menedżerem, a zespołem jednego lub dwóch.

Kevin Cline
źródło
3
(a) Wiem na pewno, że C / C ++ / Java zwykle zajmują najwyższe pozycje w konkursach programistycznych. (b) Wielu uważa C / C ++ za „najpotężniejszy język” (zdecydowanie powyżej Perla / Ruby / Pythona). (c) Z powodu przeciążenia operatora kod C ++ może wyglądać prawie identycznie jak w twoim drugim przykładzie. (d) Tak obszerne sprawdzanie (w Javie, prawda?) jest wymagane tylko wtedy, gdy: (1) Nie masz pojęcia, co robisz. (2) Charakter danych jest taki, że jest to wymagane (nie zdarza się to w konkursach kodowania). (3) Piszesz kod, który będzie używany przez inne osoby (nie dotyczy).
Dukeling,
1
@Dukeling: Według tego badania ( page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf ) języki skryptowe umożliwiają szybszy rozwój i mniejszy kod źródłowy. Według innego badania ( flownet.com/gat/papers/lisp-java.pdf ), Lisp oferuje jeszcze większą wydajność niż języki skryptowe. Według drugiego badania cytowanego powyżej kod Lisp okazuje się prawie tak szybki jak kod C ++, a jego napisanie zajmuje mniej czasu.
Giorgio
„między programem 200 000 linii a programem 40 000 linii”: Myślę, że musisz rozróżnić. Różnice wynikające z gadatliwości języka programowania (składni) nie zwiększają złożoności kodu i dlatego mogą mieć niewielki wpływ na wymagany wysiłek konserwacyjny. Z drugiej strony możesz mieć inną liczbę wierszy ze względu na różne funkcje językowe. Np. W Pythonie nie musisz zarządzać pamięcią, natomiast w C musisz samodzielnie zaimplementować całe zarządzanie pamięcią. Zgadzam się z tobą, że w kodzie C masz więcej funkcji i zdecydowanie potrzebujesz dodatkowego czasu na konserwację.
Giorgio
@Giorgio Nie spieram się o czas rozwoju lub rozmiar kodu źródłowego, a jedynie to, co faktycznie dzieje się w konkursach programistycznych, w oparciu o duże doświadczenie.
Dukeling
1
Przytoczyłem dwa artykuły naukowe (na które warto zwrócić uwagę IMO), nie mówiłem o tym, co myślą o tym ludzie na stronach internetowych. Fakt, że opinia jest szeroko rozpowszechniona, nie oznacza automatycznie, że jest ona ważna. :-) Przynajmniej trzeba to zweryfikować w jakiś rygorystyczny sposób.
Giorgio
2

Dowolny algorytm można zaimplementować w dowolnym języku programowania. W końcu nie liczy się składnia. Ale używanie języka wysokiego poziomu, takiego jak Python, ma swoje zalety. Mniej pracy i mniej kodowania. Aby więc zaimplementować algorytm w Pythonie, potrzebujesz mniej wierszy niż jest to wymagane w języku niskiego poziomu, takim jak C.

W Pythonie większość struktur danych jest wbudowanych w jego bibliotekę. Ale w C musimy zacząć od zera i użyć struktury, aby wszystko zbudować. Z pewnością istnieją różnice między językiem wysokiego i niskiego poziomu, ale język ten nie powinien powstrzymywać Cię przed implementacją jakiegokolwiek algorytmu.

Robin Thomas
źródło
2

Chociaż ekstrapolacja przykładu „40 LoC vs 200 LoC”, mówiąc: „cóż, tylko jedna piąta całego LoC jest oczywiście szybsza do pisania, więc musi być lepiej”, może wydawać się kusząca, ale naprawdę uważam, że nie ma tam wiele prawdy.

Moim zdaniem optymalizacja pod kątem najmniejszej liczby LoC prawie nigdy nie jest dobrym pomysłem. Tak, każdy napisany LoC może powodować błędy i nigdy nie musisz debugować tego, czego nigdy nie napisałeś itp. Chodzi o to, aby zoptymalizować czytelność i oddzielenie. Nie ma znaczenia, czy rozwiązujesz problem za pomocą 20-liniowego dużego wyrażenia regularnego, w przeciwieństwie do pisania modułu 1k LoC. Wyrażenie regularne będzie nieprzejrzystą ścianą, niezwykle podatną na błędy, trudną do zrozumienia, koszmarną do zmiany bez zmiany jej zachowania w niewyobrażalny sposób itp.

Pozbycie się podstawki i gadatliwości, która nie wnosi żadnej wartości, jest dobre i dobre, ale z drugiej strony, używając czegoś takiego jak Java lub C #, posiadając wiedzę o wzorcach projektowych i narzędziach takich jak resharper, dajesz tak dużą elastyczność w refaktoryzacji kodu , czyszczenie go z czasem, rozwiązywanie problemów itp., byłoby po prostu DUŻO trudniejsze, gdybyś napisał go jako znacznie mniejszy skrypt Pythona lub aplikację ruby.

Bardzo wymowne porównanie: wolałbym mieć 100k LoC pokrytego testem odsprzęgniętego kodu C #, wypełnionego „nadmiarowymi” rzeczami, takimi jak wzorzec strategii, fabryki itp., Niż 20k pytonową aplikację, która po prostu „załatwia sprawę”. 5 razy więcej kodu lub nie, architektura wygrywa każdego dnia.

W pełni zgadzam się, że niektóre rodzaje pracy są łatwiejsze i wygodniejsze w niektórych językach, ale wierzę bardziej w wybór języka na podstawie potrzebnych narzędzi i wymagań (i może być w najbliższej przyszłości).

sara
źródło