Dlaczego gadatliwość jest zła dla języka programowania? [Zamknięte]

Widziałem wielu ludzi narzekających na gadatliwość języków programowania. Uważam, że w pewnych granicach, im bardziej szczegółowy jest język programowania, tym lepiej jest go rozumieć. Myślę, że gadatliwość wzmacnia także pisanie APIdla tego konkretnego języka.

Jedyną wadą, o której mogę pomyśleć, jest to, że sprawia, że ​​piszesz więcej, ale to znaczy, większość ludzi używa IDE, które wykonują całą pracę za Ciebie.

Więc jakie są możliwe wady pełnego języka programowania?

Celem jest szybkie zrozumienie

„Pełne” oznacza „używa zbyt wielu słów”. Pytanie brzmi, czym jest „zbyt wielu”.

Dobry kod powinien być łatwy do zrozumienia na pierwszy rzut oka. Jest to łatwiejsze, jeśli większość znaków służy bezpośrednio kodowi .

Sygnał a hałas

Jeśli język jest pełny, więcej kodu to szum. Porównaj „Hello World” Javy :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... z Ruby's:

print "Hello World!"

Hałas marnuje energię psychiczną.

Cryptic vs. Clear

Z drugiej strony nadmierna zwięzłość języka również kosztuje energię psychiczną. Porównaj te dwa przykłady z Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

Wpływa na to, ile kodu można zobaczyć i parsować jednym spojrzeniem

x++ zamiast set(x,Integeradd(get(x),1))

ps. Nie chodzi tylko o czytanie kodu. W czasach ekranów 40 x 25 języki APL lub Perl były przydatne w Cobol lub Fortran pod względem ilości kodu, który można odczytać / stronę. Ale teraz chodzi bardziej o twoją wewnętrzną pamięć podręczną - jeśli instrukcja ma jednego operatora, mój starzejący się mózg łatwiej analizuje niż jeden z 3 symbolami i 4 wywołaniami funkcji.

Jeśli gadatliwość języka szkodzi czytelności kodu, jest zła.

Niektóre języki mają taką pełną składnię, że zrozumienie znaczenia kodu trwa dłużej (myślę o VB.NET w porównaniu do C #):

If something Then
End If

if(something)
{}

To naprawdę sprowadza się do tego, co programista zna i czuje się komfortowo.

Spójrz na AppleScript , jeden z najbardziej gadatliwych języków, które mogę wymyślić, które można uznać za aktualny , spróbuj napisać w nim coś trywialnego i wróć i spróbuj argumentować, że gadatliwość jest dobrą cechą w języku.

Próba zapamiętania całej semantyki tego, gdzie idą słowa kluczowe i co to są, nie jest trywialna, jeśli nie robisz tego codziennie.

Wystarczy spojrzeć na wszystkie słowa kluczowe hałas w tym trywialnym przykładzie:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

przyznanie tego samego w bashprzypadku tradycyjnych narzędzi uniksowych byłoby zwięzłe, ale tajemnicze dla większości użytkowników OSX, więc należy zachować równowagę.

Myślę, że musisz postawić pytanie na głowie i zapytać: Dlaczego niektórzy ludzie uważają, że zwięzły kod jest dobry?

Moja odpowiedź byłaby taka, że ​​istnieją dwa podstawowe powody:

Powody, dla których Terse może być lepszy

Obejmują one większą czytelność, podobnie jak krótkie zdanie może być bardziej zrozumiałe niż kwieciste zdanie pełne. Często języki programowania, które próbują naśladować gramatykę języka angielskiego, są okropnie długie, co wymaga ogromnej ilości kodu do wykonania najprostszych czynności. Często okazuje się, że im bardziej język emuluje język pisany, tym trudniej jest go przekonać do wykonywania logicznie skomplikowanych operacji.

Powody, dla których Terse może być gorzej

Niektóre języki (a myślę o Perlu) używają szeregu dziwnych symboli, które wydają się być prawie arbitralnie wybrane, jako część ich składni. Dla każdego, kto nie zna tych hieroglifów, język staje się nieprzenikniony. Łatwo jest również popełniać błędy literowe, które nie są łatwo widoczne. Wyrażenia regularne mogą być uosobieniem tego rodzaju zwięzłości.

Ponadto niektórzy ludzie lubią się popisywać pisząc zwięzły kod, ponieważ, szczerze mówiąc, myślą, że dzięki temu wyglądają sprytniej. Czasami można to zobaczyć na StackOverflow, gdzie ludzie często przesyłają odpowiedzi, które są niezwykle zwarte kosztem czytelności. Jest to rodzaj „imponowania rówieśnikom” tym, jak dobrze znasz filozofię, ale dobrzy programiści zdają sobie sprawę, że „ golf golfowy ” nie jest sposobem na tworzenie oprogramowania, które można utrzymać.

@frowing, sugerowałbym, że jednym ze sposobów spojrzenia na kwestię gadatliwości jest uświadomienie sobie, że programowanie to zawsze połączenie dwóch raczej różnych stylów znalezienia i wyrażenia rozwiązania.

Pierwszym i bardziej pełnym stylem jest programowanie zorientowane na język (językoznawczy). Ten styl łączy słowa podobne do rzeczowników i słowa podobne do czasowników w strukturach podobnych do zdań i jest przeznaczony do czytania i rozumienia w taki sam sposób, jak dobrze napisany akapit. Programowanie językowe jest najbardziej uniwersalnym stylem programowania, ponieważ sam język jest uniwersalny. Z tego samego powodu długoterminowe wsparcie programu zawsze wymaga potężnego komponentu językowego, ponieważ pierwszą rzeczą, której szuka nowy programista, jest koncepcyjne zrozumienie tego, co się dzieje. Zasadniczo im dalej od kontekstu, w którym utworzyłeś program, tym ważniejszy będzie język programowania, aby upewnić się, że twoje założenia i koncepcje nie zostaną źle zrozumiane przez następną osobę próbującą zrozumieć Twój kod .

Drugi i bardziej zwięzły styl to programowanie matematyczne (matematyczne). Ten styl rozumowania zależy również od języka, ponieważ na przykład zmienne są analogiczne do rzeczowników, a operatory do czasowników. Jednak rozumowanie matematyczne wykorzystuje niesamowitą i wysoce równoległą zdolność naszych mózgów do wykonywania złożonych transformacji przestrzennych na obiektach znajdujących się w naszej linii widzenia. Reprezentując rzeczowniki i czasowniki jako zwarte, charakterystyczne symbole, które można ułożyć w dobrze ustrukturyzowane wyimaginowane obiekty - równania - możemy następnie wykorzystać nasze wysoce równoległe możliwości wizualne do wykonywania obrotów, zamian, ruchów, inwersji i innych przekształceń na tych wyobrażonych przedmioty Rezultatem jest ogromne zwiększenie liczby przypadków, które możemy obsłużyć jednocześnie, ponieważ każdy symbol może reprezentować całe klasy blisko spokrewnionych obiektów.

Zauważ, że aby efektywnie zastosować przetwarzanie wizualne, musisz utrzymywać swój wymyślony obiekt tak podobny, jak to możliwe, pod względem wielkości i cech do rzeczywistego obiektu. Jeśli potrzebne pole widzenia staje się zbyt szerokie lub symboli nie można używać jak ruchomych znaków na obiekcie, lub jeśli trzeba „czytać litery” i konwertować je na słowa, zdolność niezawodnego wykonywania złożonych przekształceń spadnie szybko nawet dla bardzo dobrego matematyka.

Dlatego ludzie głęboko zanurzeni w matematycznym stylu programowania mogą stać się poważnie niezadowoleni, jeśli równanie zostanie rozłożone i wyrażone w tak zwanym „pełnym” stylu językowym. Nie dlatego, że równanie zostało znacząco zmienione, ale dlatego, że takie jego rozłożenie może prawie uniemożliwić zastosowanie wizualnego stylu zrozumienia. Jednocześnie jednak nowy programista, który wcale nie jest zaznajomiony z krótkimi symbolami, prawdopodobnie preferuje bardziej szczegółową wersję, która zapewnia więcej informacji językowych do początkowego zrozumienia działania kodu.

Co więc poleciłbym?

Użyj obu stylów, ale zwróć szczególną uwagę na to, dlaczego używasz każdego z nich.

Na przykład wszystko, co ma szansę na kontakt ze światem zewnętrznym, powinno być na pewnym poziomie intensywnie gadatliwe, nawet jeśli tylko w formie komentarzy wewnętrznych połączonych z kodem, i powinno również obejmować automatyczne sprawdzanie poprawności użycia. Zaszyfrowane, a zwłaszcza niekompletnie zdefiniowane notacje nie mają nic wspólnego z takimi interfejsami, ponieważ prawie na pewno w pewnym momencie zostaną źle zrozumiane. Utrata Mars Climate Obiter w 1999 r. Z powodu nierozpoznania, czy jednostki interfejsu oprogramowania zostały wyrażone w funtach czy Newtonach, jest szczególnie wyraźnym przykładem niebezpieczeństwa polegającego na zbyt swobodnym poleganiu na surowych liczbach w interfejsach programowych lub sprzętowych.

I odwrotnie, każda forma programowania, która jest z natury głęboko algorytmiczna i matematyczna, jest dobrym kandydatem na zwięzłe programowanie, które obsługuje matematyczny styl rozumowania. Jeśli ktoś nowy musi zachować taki kod, zwykle lepiej jest nauczyć się notacji matematycznych niż próbować przekształcić kod w bardziej pełne formy. Oczywiście zawsze powinna być łatwo dostępna dokumentacja wyjaśniająca matematyczne części kodu dostępnego dla takich programistów, ale jest to osobna kwestia.

Pomiędzy tymi ekstremami jest wiele przypadków, w których programista ma znaczną dyskrecję. Proponuję przyjrzeć się, w jaki sposób kod będzie utrzymywany w perspektywie długoterminowej, i starać się zaspokoić potrzeby osób, które prawdopodobnie utrzymają kod w perspektywie długoterminowej.

Wiele osób wskazało na coś, co moim zdaniem powinno być wyraźnie określone.

Gadatliwość sprzyja zrozumieniu na poziomie mikroskopowym - generalnie prowadzi do tego, że indywidualne stwierdzenie jest łatwe do odczytania i zrozumienia. Gadatliwość ma również tendencję do zmniejszania stopnia znajomości języka niezbędnego do jego zrozumienia (przynajmniej do pewnego stopnia). Najbardziej szczegółowe języki (np. COBOL) mogą być przynajmniej w pewnym stopniu czytelne nawet dla kompletnych nieprogramistów.

Konkluzja zmierza w przeciwnym kierunku: pomaga zrozumieć na poziomie makroskopowym, szczególnie przez programistów, którzy mają najgłębszą znajomość tego konkretnego języka. Jednocześnie brak znajomości tego konkretnego języka może uniemożliwić nawet podstawowe zrozumienie, nawet ze strony programistów, którzy w innym przypadku byliby dość doświadczeni.

W związku z tym czytelność różni się znacznie w zależności od grupy docelowej. Z jednej strony rozważmy, że duży, złożony projekt jest napisany i prowadzony przez osoby, które pracują prawie wyłącznie nad tym projektem, z których większość ma znaczne wykształcenie programistyczne i wykształcenie (np. Wiele doktoratów). Sprzyja to bardziej zwięzłemu językowi.

Mniej więcej przeciwnie, rozważ projekt, który jest znacznie prostszy (choć być może wciąż dość duży), który jest prowadzony przede wszystkim przez ludzi, którzy naprawdę specjalizują się w działalności związanej z oprogramowaniem, a nie z samym oprogramowaniem. To prawie na pewno faworyzuje bardziej szczegółowy język.

Zamiast iść do książki technicznej, wracam do Elements of Style * autorstwa Strunk and White. Podstawową koncepcją jest „Bądź precyzyjny” i „Nie mów więcej niż to konieczne”. Cała reszta to komentarz.

W programowaniu chodzi o to, by być bardzo precyzyjnym, ale nie mieć zbędnego puchu. Dodatkowy puch może być składniowy, ale może także zawierać więcej słów niż jest to wymagane do przekazania znaczenia. (Oczywiście nie jest też za mało, aby umożliwić dwuznaczność)

• Cytuję oryginalną wersję, ponieważ jest ona najbardziej zwięzła. :-)

Pod koniec dnia wszystko, co „inne” spowoduje, że ludzie wyją. Czuję się swobodnie ze składnią w stylu C, a zatem dobrze z innymi językami o podobnej składni (C ++, Java, C #). Więc mam tendencję do faworyzowania tego konkretnego stylu.

Języki mają tendencję do znajdowania równowagi między wystarczająco opisowym, a nie pełnym.

Perl jest przykładem, gdzie możesz napisać bardzo zwięzły kod. Dla niewtajemniczonych kod napisany przez ninja Perla to magia.

COBOL jest przykładem zbyt gadatliwym.

Czytałem kiedyś gdzieś, że duża część szczegółowej debaty pochodzi od nowych programistów kontra stare ręce. Zastosowana analogia była taka, że ​​kiedy uczymy się czegoś nowego, opowiadamy sobie „historię”, aby się przez to przejść (pomyśl o tym, kiedy nauczyłeś się algebry w HS). W miarę zdobywania doświadczenia wychodzimy poza potrzebę opowiadania wyjaśniającego poszczególne elementy i rozumiemy większą ich liczbę. Nasz kod staje się gęstszy i bardziej zwięzły, a komentarze wyjaśniają tylko niezbędne elementy, zamiast powtarzać to, co mówi kod.

Odkryłem, że to prawda między mną a współpracownikiem. Pisze kod z mnóstwem komentarzy wyjaśniających, jakie są wiersze kodu i dużą ilością białych znaków. Jeśli to czytam, stwierdzam, że z tego powodu mogę zmieścić tylko kilka wierszy kodu na jednym ekranie. To sprawia, że ​​zrozumienie każdej linii jest znacznie łatwiejsze, ale omawianie całej funkcji staje się znacznie trudniejsze.

Zwykle piszę kod bez dodatkowych białych znaków i komentarzy. To sprawia, że ​​oglądanie całości jest znacznie łatwiejsze, ale musisz być w stanie po prostu „zdobyć” poszczególne słowa „kodu”. Jeśli spróbujesz przeczytać tę odpowiedź, gdy każde słowo znajduje się w osobnym wierszu, z dużą ilością białych znaków / komentarzy / dodatkowego słownictwa, znacznie łatwiej będzie zrozumieć każde słowo, ale o wiele trudniej zrozumieć całość.

Einstein miał rację: „Spraw, aby wszystko było tak proste, jak to możliwe, ale nie prostsze”.

Dotyczy to również kodu. Jeśli możesz uprościć kod poprzez usunięcie powtarzających się i niepotrzebnie pełnych elementów, to dobrze.

Ponadto niektóre studia przypadków sugerują, że produktywność programisty mierzona w liniach kodu jest mniej więcej stała. Tak samo jak liczba błędów na LOC. Dlatego przejście na język, który pozwala robić więcej na wiersz kodu, można uznać za poprawę wydajności, jeśli wszystkie inne rzeczy pozostaną takie same.

Biorąc to pod uwagę, w tej branży występuje tendencja do nadmiernej inżynierii i komplikowania prostych rzeczy. Proste rzeczy, takie jak umieszczanie danych kontaktowych w relacyjnej bazie danych. Widziałem kilka absurdalnie skomplikowanych i błędnych rozwiązań ( kaszel MDA) dla tego konkretnego problemu. Języki takie jak Scala i Ruby są dobrymi przykładami potężnych narzędzi, które w rękach niektórych osób powodują niezrozumiały, zbyt skomplikowany i trudny w utrzymaniu kod. To, że możesz użyć wielu poziomów pośrednich za pomocą kilku klawiszy, nie oznacza, że ​​musisz wyrywać każdy gwóźdź w zasięgu wzroku za pomocą tego konkretnego młotka.

Przy właściwym użyciu otrzymujesz ładny, czysty kod, który jest zarówno krótki, jak i łatwy do zrozumienia. W przypadku złego użycia lepiej jest ograniczyć daną osobę do używania języka Visual Basic lub podobnie ograniczonego języka, aby zapobiec dalszym szkodom.

Prawdziwa umiejętność polega na robieniu skomplikowanych rzeczy w prosty sposób, a nie na robieniu prostych rzeczy w skomplikowany sposób.

Coś, czego nikt inny nie trafił, to ilość kodu, którą można zmieścić na jednym ekranie. Pomaga z kilku powodów:

• Mniej przewijania w przód iw tył, gdy pracujesz (lub czytasz) wiele funkcji w jednym pliku.
• Mniej przewijania w poziomie (zatrzymaj czytanie, kliknij i przeciągnij pasek przewijania, zatrzymaj czytanie, kliknij i przeciągnij pasek przewijania ...).
• Szybsze skanowanie, ponieważ mniej niepotrzebna składnia przeszkadza w znalezieniu tego, czego chcesz.

Ponieważ więcej kodu oznacza dłuższy czas programowania i więcej błędów.

Jeśli napiszesz 100 wierszy kodów zamiast 300 wierszy kodów. Oznacza to prawie 1/3 potrzebnego czasu rozwoju i 1/3 potencjalnych błędów, które możesz napotkać.

W większości przypadków trzeba zrównoważyć wydajność i zwięzłość, ponieważ pisanie mniejszej liczby kodów oznacza, że ​​maszyna musi robić więcej rzeczy, co obniża wydajność.

Zwykle ludzie wolą języki czytelne / pełne niż kryptyczne / zwięzłe. Myślę jednak, że większość ludzi przyswoiła sobie „gadatliwość” z „bałaganem”, które nie są tym samym.

Na przykład: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

jest bardzo zwięzłym stwierdzeniem. Zawiera wszystko, co chcesz wiedzieć. Jednak ze względu na zwięzłość trudno ją zrozumieć. Z drugiej strony nieco bardziej szczegółowa wersja tego samego programu byłaby dość łatwa do zrozumienia, ponieważ jest bardziej czytelna. Oczywiście nie jest to właściwość języka jako takiego, ale niektóre języki mają tendencję do większej gadatliwości, podczas gdy inne mają tendencję do bardziej zwięzłego sposobu programowania.

Do drugiej skrajności gadatliwości należy http://en.wikipedia.org/wiki/Literate_programming , co uważam za dość interesującą koncepcję.

Innym aspektem jest „niechciana gadatliwość”, zwana także „bałaganem”. Rzeczy, które musisz dodać z przyczyn technicznych, brak cukru syntaktycznego, rozdęte API i tak dalej.

Myślę, że jasna i intuicyjna składnia jest bardzo ważna. Musi być również wystarczająco szczegółowe, aby ułatwić czytanie. Zbyt krótkie wypowiedzi wypełnione zbyt dużą logiką mogą często prowadzić do rozszyfrowania więcej niż ich nieco dłuższe odpowiedniki. Z drugiej strony, bezużyteczny, rozdęty kod pełen linii kotłów do zrobienia czegoś całkowicie prostego jest równie uciążliwy.

Gadatliwość to tendencja do używania dużej ilości tekstu, a zwięzłość użycie bardzo małej ilości tekstu ...

Gadatliwość jest zła, ponieważ:

1. wprowadza więcej okazji do błędów typograficznych
2. utrudnia to czytanie kodu na ekranie lub papierze i / lub wprowadzanie na karcie dziurkacza
   1. wydłuża to czas debugowania
   2. utrudnia to zrozumienie kodu do aktualizacji / konserwacji
   3. może to prowadzić do niezamierzonego powielania kodu
3. zwiększa to nieco prawdopodobieństwo błędu składniowego
4. zmniejsza elastyczność kodowania, przez co większość pełnych języków ma wysoce uporządkowaną strukturę i nie ma wielu sposobów na powiedzenie tego samego.
5. wydłuża czas kodowania i kompilacji
6. może zająć więcej miejsca.

Pewny poziom szczegółowości jest niezbędny dla jasności, jednak ...

minimalny poziom gadatliwości jest dobry, ponieważ:

1. ludziom łatwiej jest odczytać i przypisać wartość semantyczną niż kodowi czysto symbolicznemu
2. W nazwach zmiennych i funkcji ułatwia debugowanie, przenoszenie i obsługę kodu
3. w operacjach języka podstawowego i słowach kluczowych w złożonych językach prowadzi to do mniejszej liczby niepoprawnych przypisań operacji / słów kluczowych.

Niektóre wspaniałe przykłady zbyt lakoniczny poleceń dla wielu ludzi to stare PODSTAWOWE standbys val(x$), str$(x)i chr$(x)... powrót numer z jej ciąg znaków, powrót na ciąg liczb, a także zwraca pojedynczy znak mający wartość ASCII X jako ciąg znaków.

Lub wskaźnik C / C ++ i operatory referencyjne &oraz w *porównaniu ze byrefsłowem kluczowym BASIC . W C / C ++ mogę mieć zmienną X i przekazać wskaźnik do tej zmiennej, ale muszę pamiętać, który to wskaźnik, a który to „użyj wskaźnika jako zmiennej, na którą wskazuje”; w zasadzie po prostu przekazuję odwołanie słowem kluczowym byref w wywołaniu funkcji, co jest bardziej jasne, ale mniej elastyczne:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

W tym kodzie zawartość x jest modyfikowana z powodu flagi byref. Niektóre smaki pozwalają byref na telefon, inne w definicji, niektóre w obu.

Szczegółowość jest ważna dla zwykłych programistów, aby mogli łatwiej korzystać z symboliki; BASIC lub python są bardziej czytelne dla ludzi i bardziej gadatliwe niż C / C ++, a zatem znacznie bardziej przydatne dla zwykłych programistów; zwięzłość C / C ++ sprawia, że ​​jest to znacznie lepsze dla bardziej doświadczonych programistów, którzy muszą zobaczyć więcej kodu i bardziej złożony kod na jednym ekranie, ale musieli nauczyć się różnych konwencji struktury symbolicznej. Na drugim końcu znajduje się APL, który jest prawie całkowicie nieczytelny dla człowieka.

Powiązanym ze sobą problemem jest przejrzystość - zwięzły kod jest często niejasny, a nadmiernie szczegółowy kod (jak w AppleScript) może być równie niejasny. Znajomość danego języka zwiększa przejrzystość zwięzłego kodu w tym języku - surowy początkujący, stojący w obliczu kodu C ++ prawdopodobnie będzie w stanie analizować tylko formuły, a nawet bardzo funkcjonalny kod BASIC lub Python jest zbyt krótki, aby go zrozumieć, ale AppleScript potrafi być zaskoczonym, ogólnie rzecz biorąc, bez uciekania się do słowników językowych. Najmniej jasne, jakie spotkałem bez celowego zaciemniania, to Inform 7 ...

W dawnych czasach

Innym ważnym zagadnieniem w przeszłości, ale tym, które nie jest już tak ważne dla programisty hobbystycznego, jest obsługa i przestrzeń do przechowywania. (W dalszym ciągu jest to niezwykle ważne.) Pamiętając, że zinterpretowano wiele języków, zwłaszcza BASIC, a wiele innych zostało skompilowanych w czasie wykonywania, przestrzeń kodu była ważna, szczególnie gdy dyski miały tylko 128 KB, a pojedyncze karty dziurkaczy tylko 80 B.

Istniało kilka rozwiązań - tokenizacja była niezwykle powszechna w języku BASIC; poszczególne słowa kluczowe w języku zostały zredukowane do 1 lub 2 bajtowego słowa w górnej 128 lub w przestrzeni kontrolnej. Tokenizacja prowadzi również do kompilacji kodu bajtowego (jak w Inform i Z-Machine).

Do obejścia ograniczeń przestrzeni wykorzystano także kompilację i łączenie wielu plików obiektowych. Sekcja kodu Pascal 100 kB może zostać skompilowana tylko do 5 kB; łącząc wiele skompilowanych plików, można budować masywne aplikacje bez dostępu do dysków wielkoformatowych (pamiętając, że 10 MB był zadziwiająco duży, a drogi zakup nowego samochodu).

Jednak więcej zwięzłych języków dostało więcej kodu do danego fragmentu dysku i pamięci RAM, a tym samym skompilowało większe fragmenty naraz. Pamiętając: „minikomputery” z początku lat 70. XX wieku mogły mieć tylko 64 kB pamięci RAM (Honeywell 800 miał podstawową instalację 4 banków po 2048 słów po 8B każdy). APL i podobne języki symboliczne zbliżyły się do 1B na instrukcję plus jej operandy, w porównaniu do znacznie większej 3B-10B na instrukcję plus operandy. (Pisanie na kartach punktowych było koszmarem, zwłaszcza, że ​​symbole były zasadniczo czcionką na typ-ball, a wiele kart nie miało symboli na klawiszach ...)

Pamiętaj też, że kart nie można usunąć ... i wiele programów wprowadzono na kartach. Chociaż nie jest to indywidualnie drogie, im bardziej skompresowany kod może znajdować się na karcie, tym mniej potrzebujesz, i tym większe mogą być programy lub mniej kosztowne. Jest to jeden z powodów, dla których BASIC łączy wiele instrukcji na linię w większości odmian - wprowadzono, aby oszczędzać na kartach poncz. (A przynajmniej tak mówi mój tekst programowania Vax Basic.) Chociaż nie zaprogramowałem czytnika kart, wykonałem wykrawanie kart dla Honeywell 800 w FORTRAN, BASIC, APL i kilku innych wysoce symbolicznych językach.

Podobnie jak w przypadku tak wielu rzeczy, odpowiedź zależy od konkretnej definicji „gadatliwości”. Jeśli definicja jest taka, że ​​gadatliwość oznacza nadmiarowość, to twierdzę, że zawsze jest zła. Zauważ, że przy takiej definicji często cytowany program Java hello world nie kwalifikowałby się jako „pełny”, ponieważ nie ma w nim nic zbędnego.

Programiści lubią języki z ekspresyjną mocą, ponieważ pozwala im zakodować proste rzeczy, które często muszą być wykonywane często, w małych kawałkach kodu. Pełne języki zwykle oznaczają, że wiele, wiele wierszy kodu musi być używanych do robienia tego samego w kółko. Jednak ekspresywne języki mogą być płatne, ponieważ ich realizacja nie jest tak szybka, jak prostsze języki wysokiego poziomu. Jeśli mogę podać przykład w przeciwieństwie do C i C ++. C ++ daje twórcom kodu bardziej ekspresyjną moc - mogą oni zawrzeć ideę obiektów świata rzeczywistego w klasach. Programiści C mogą osiągnąć te same rzeczy, ale mają ekspresyjną moc konstruktu klasowego, aby im pomóc - tak często muszą pisać dłuższy, bardziej skomplikowany (aby zrozumieć) kod. Ale ten kod może działać szybciej (chociaż jest to wysoce zależne od jakości kompilatora itd.), Ponieważ nie używa „późnego wiązania” C ++ (tj. Refaktoryzacji w czasie wykonywania) do wykonania kodu. C po prostu wykonuje skompilowany i połączony kod, C ++ musi podjąć decyzję (w pewnych okolicznościach) w czasie wykonywania o tym, które fragmenty kodu wykonać.

Uważam, że odpowiedź na to pytanie jest zakorzeniona w bardziej fundamentalnym i teoretycznym zagadnieniu niż czytelność i ta odpowiedź jest związana z algorytmiczną teorią informacji stworzoną przez Gregory'ego Chaitina: http://en.wikipedia.org/wiki/Al Algorytmic_information_theory . Mówiąc w kilku słowach: „zawartość informacji ciągu znaków odpowiada długości najkrótszej możliwej niezależnej reprezentacji tego ciągu”, oznacza to, że najkrótszy program (mianowicie pod względem długości leksykograficznej) ściśle rozwiązuje dany problem odpowiada wewnętrznej złożoności problemu, któremu daje rozwiązanie, a zatem zależy bardziej od natury problemu, a mniej od reprezentacji problemu.