Dlaczego wciąż zmieniane są stare języki programowania?

To pytanie nie brzmi: „Dlaczego ludzie nadal używają starych języków programowania?” Rozumiem to całkiem dobrze. W rzeczywistości dwa języki programowania, które znam najlepiej, to C i Scheme, z których oba pochodzą z lat 70.

Ostatnio czytałem o zmianach w C99 i C11 w porównaniu do C89 (która nadal wydaje się być najczęściej używaną wersją C w praktyce i wersją, której nauczyłem się od K&R). Rozglądając się, wydaje się, że każdy intensywnie używany język programowania otrzymuje nową specyfikację przynajmniej raz na dekadę. Nawet Fortran wciąż otrzymuje nowe wersje, mimo że większość osób korzystających z niego nadal używa FORTRAN 77.

Porównaj to z podejściem, powiedzmy, systemu składu TeX. W 1989 roku wraz z wydaniem TeX 3.0 Donald Knuth zadeklarował, że TeX jest kompletny, a przyszłe wydania będą zawierać tylko poprawki błędów. Nawet poza tym stwierdził, że po jego śmierci „wszystkie pozostałe błędy staną się funkcjami” i absolutnie nie będą dokonywane żadne dalsze aktualizacje. Inni mogą rozwidlać TeX i zrobili to, ale nazwy systemów wynikowych zmieniają się, aby wskazać, że różnią się od oficjalnego TeXa. Nie dlatego, że Knuth uważa, że ​​TeX jest doskonały, ale dlatego, że rozumie wartość stabilnego, przewidywalnego systemu, który zrobi to samo za pięćdziesiąt lat, co teraz.

Dlaczego większość projektantów języków programowania nie stosuje tej samej zasady? Oczywiście, gdy język jest stosunkowo nowy, sensowne jest, że przejdzie on okres szybkiej zmiany, zanim się ustabilizuje. I nikt nie może tak naprawdę sprzeciwić się drobnym zmianom, które nie robią nic więcej, jak tylko skodyfikować istniejące pseudo-standardy lub poprawić niezamierzone odczyty. Ale kiedy język wydaje się wymagać poprawy po dziesięciu lub dwudziestu latach, dlaczego nie po prostu rozwidlić go lub zacząć od nowa, zamiast próbować zmienić to, co już jest używane? Jeśli niektórzy ludzie naprawdę chcą programować obiektowo w Fortranie, dlaczego nie stworzyć w tym celu „Objective Fortran” i zostawić Fortran w spokoju?

Przypuszczam, że można powiedzieć, że bez względu na przyszłe wersje, C89 jest już standardem i nic nie stoi na przeszkodzie, aby ludzie nadal go używali. To trochę prawda, ale konotacje mają konsekwencje. W trybie pedantycznym GCC ostrzega przed składnią, która jest albo przestarzała, albo ma nieco inne znaczenie w C99, co oznacza, że ​​programiści C89 nie mogą całkowicie zignorować nowego standardu. Dlatego w C99 musi być jakaś korzyść, która wystarczy, aby narzucić to obciążenie wszystkim, którzy używają tego języka.

To prawdziwe pytanie, a nie zaproszenie do kłótni. Oczywiście mam opinię na ten temat, ale w tej chwili staram się zrozumieć, dlaczego nie chodzi już o to, jak już się to robi. Przypuszczam, że pytanie brzmi:

Jakie są (rzeczywiste lub postrzegane) zalety aktualizacji standardu językowego, w przeciwieństwie do tworzenia nowego języka opartego na starym?

Myślę, że motywacją dla projektantów języków do zmiany istniejących języków jest wprowadzenie innowacji przy jednoczesnym zapewnieniu, że docelowa społeczność programistów pozostanie razem i przyjmie nowy język: przeniesienie istniejącej społeczności do nowej wersji istniejącego języka jest bardziej skuteczne niż tworzenie nowej społeczności w nowym języku. Oczywiście zmusza to niektórych programistów do przyjęcia nowego standardu, nawet jeśli byłby w porządku ze starym: w społeczności czasami trzeba narzucić pewne decyzje mniejszości, jeśli chce się utrzymać społeczność razem.

Weź również pod uwagę, że język ogólnego przeznaczenia próbuje obsłużyć jak najwięcej programistów i często jest stosowany w nowych obszarach, dla których nie został zaprojektowany. Dlatego zamiast dążyć do prostoty i stabilności projektu, społeczność może zdecydować się na wprowadzenie nowych pomysłów (nawet z innych języków) w miarę, jak język przechodzi do nowych obszarów zastosowań. W takim scenariuszu nie można oczekiwać, że uda się to za pierwszym razem.

Oznacza to, że języki mogą ulegać głębokim zmianom na przestrzeni lat, a najnowsza wersja może wyglądać zupełnie inaczej niż pierwsza. Nazwa języka nie jest zachowywana ze względów technicznych, ale dlatego, że społeczność programistów zgadza się używać starej nazwy dla nowego języka. Zatem nazwa języka programowania identyfikuje społeczność jego użytkowników, a nie sam język.

IMO motywuje, dlaczego wielu programistów uważa to za dopuszczalne (a nawet pożądane), że stopniowe przejście do nieco innego języka jest łatwiejsze i mniej mylące niż przejście do zupełnie nowego języka, którego opanowanie zajęłoby im więcej czasu i wysiłku. Weź pod uwagę, że istnieje wielu programistów, którzy mają jeden lub dwa ulubione języki i niezbyt chętnie uczą się nowych (radykalnie różnych) języków. I nawet dla tych, którzy lubią uczyć się nowych rzeczy, nauka nowego języka programowania jest zawsze trudnym i czasochłonnym zajęciem.

Lepiej też być częścią dużej społeczności i bogatego ekosystemu niż bardzo małej społeczności używającej mniej znanego języka. Tak więc, kiedy społeczność decyduje się na kontynuację, wielu członków decyduje się pójść dalej, aby uniknąć izolacji.

Na marginesie uważam, że argument dopuszczenia ewolucji przy zachowaniu zgodności ze starszym kodem jest raczej słaby: Java może wywoływać kod C, Scala łatwo integruje się z kodem Java, C # może integrować się z C ++. Istnieje wiele przykładów, które pokazują, że możesz łatwo łączyć się ze starszym kodem napisanym w innym języku bez potrzeby zgodności kodu źródłowego.

UWAGA

Z niektórych odpowiedzi i komentarzy wydaje mi się, że niektórzy czytelnicy zinterpretowali pytanie jako „Dlaczego języki programowania muszą ewoluować”.

Myślę, że nie jest to główny punkt pytania, ponieważ oczywiste jest, że języki programowania muszą ewoluować i dlaczego (nowe wymagania, nowe pomysły). Pytanie brzmi raczej: „Dlaczego ta ewolucja musi nastąpić w języku programowania, zamiast pojawiać się wielu nowych języków?”

Kompatybilność wsteczna jest twoją odpowiedzią. Dany język, szczególnie powszechnie używany, taki jak C, może mieć kod działający niezmieniony przez dziesięciolecia. Jeśli zachodzi potrzeba konserwacji, pomaga mieć kompilatory, które mogą nadal celować w tego rodzaju platformę, pracując na nowoczesnych systemach do prac programistycznych. Standaryzacje i aktualizacje wersji językowych pomagają utrzymać aktualność praktyk programistycznych, zapewniając jednocześnie poczucie znajomości dla doświadczonych programistów, którzy mogą być odporni na naukę całego „nowego” języka.

Należy pamiętać, że wiele zaktualizowanych języków jest mniej zaktualizowanych, a „mają nowe błyszczące elementy”. W przeszłości czają się często bestie.

Jeśli chodzi o Knutha, pamiętaj, że jest on akademikiem i że TeX jest tylko poprawny, a nie zaktualizowany.

Myślę, że oczywistą odpowiedzią jest to, że nadal postępuje się w projektowaniu języków i architekturze systemu, a wystarczająca liczba osób dba o starsze języki, aby chciały skorzystać z nowszych technik (wiele rdzeni, lepszych wątków lub modeli pamięci), które dostają na lub upieczone w standardzie językowym. Pomaga także mieć „jeden prawdziwy sposób” na robienie rzeczy (np. Parsowanie XML, dostęp do bazy danych), na których możesz polegać bez względu na to, na jakim kompilatorze lub platformie się znajdujesz, w przeciwieństwie do zależności od niektórych firm zewnętrznych biblioteka, która może być lub nie być zainstalowana (i może być lub nie wymagana wersja, itp.).

Podstawowe pojęcia lub cele, na których opiera się język ogólnego przeznaczenia, nie tracą znaczenia; jednak niewielkie zmiany w środowisku pracy lub sprzęcie wymagają dodania aktualizacji lub drobnych funkcji do języka.

Sposób, w jaki algorytmy są wyrażane w języku, nie ulegnie zmianie, nawet jeśli może to wymagać bardziej przejrzystej obsługi 64-bitowych typów lub bardziej standardowej obsługi wyrażeń regularnych lub bardziej niezawodnej obsługi nowych typów systemów plików.

Istnieje kilka przypadków, w których „nowe” funkcje są dodawane do istniejących języków, ale w wielu przypadkach zmiany te sprowadzają się do uproszczenia tego, co ludzie robili już ciężko. (Zobacz C ++ przy użyciu funkcji wyższego rzędu zamiast wskaźników funkcji i funktorów.)

To trochę przypomina rozważanie języka mówionego.

W przeszłości słowa, które nie były używane tak często, jak teraz (lub używane w innym znaczeniu).

na przykład. nice: w (bardzo starym) języku angielskim ma prawie odwrotne znaczenie w stosunku do tego, którego używamy dzisiaj, szczególnie gdy jest używany do opisu czyjegoś znaku.

Źle: nie tak dawno temu złe miało tylko jedno znaczenie, teraz może oznaczać coś, co jest „super niesamowite” (jest używane w sposób fesiczny (prawdopodobnie przegapiłem fesicous)!

Kolejnym nowym rozwiązaniem jest telefon komórkowy „Text speak” dla języków pisanych.

Nie rozumiem osobiście, dlaczego język programowania nie rozwija się w podobny sposób, słowa i funkcje mają określone znaczenia / działania i należy je zmienić, aby uwzględnić nowe pomysły, nowe metodologie.

Znam ludzi, którzy mówią wieloma różnymi językami, i często sugerują, że po 3. lub 4. łatwiej jest nauczyć się nowego.

Nie wiem, czy są programiści, którzy mają podobne doświadczenia, nie byłbym zaskoczony, gdyby tak było.

Wiem, że czuję się szczęśliwy, programując w JAVA (tak samo, jak czuję się szczęśliwy, mówiąc po angielsku) Nie oznacza to, że nie mogę komunikować się w języku „amerykański angielski” lub „australijski angielski”, chociaż jest kilka „gotchas”, na które trzeba uważać . Podobnie jak przejście z Javy na PHP na Perla, konstrukcje są podobne, ale są małe problemy, które mogą mnie złapać i zmusić do uderzenia głową o ścianę.

Różni się to od przejścia z angielskiego na francuski lub Java na SAS. są tak różne, że ich opanowanie zajmuje sporo czasu.

W każdym razie to moje zdanie na ten temat.