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

46

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?


źródło
2
Wiele kompilatorów można wywoływać za pomocą przełączników, które będą wymuszać starsze standardy (np. --std=xPrzełącznik GCC ), więc nie jest tak, jakby tworzenie nowych standardów skutkowało narzędziami destabilizującymi starszy kod.
Blrfl
2
Jak definiujesz „nowy język oparty na starym”? Twierdziłbym, że Fortran 90 to „nowy język” oparty na starym F77. Całkowicie zmieniło to, jak programujesz - stała vs wolna wersja, pamięć dynamiczna vs. Brzmi jak związek między C ++ i C.
tpg2114
1
Myślę, że to pytanie jest bardzo ważne i nie rozumiem, dlaczego niektórzy chcą je zamknąć. To bardzo interesujące zjawisko, które prawdopodobnie ma jakieś wytłumaczenie. Kilka (20?) Lat temu czytałem o nowych funkcjach Fortrana i zadałem sobie pytanie: jeśli programiści Fortran potrzebują tych funkcji, dlaczego po prostu nie przechodzą na C? Ostatnio miałem podobne zdanie na temat C ++: jeśli programiści C ++ chcą używać lambdas, dlaczego nie przejść na, powiedzmy, OCaml ( linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php )? Dlaczego wolą stworzyć nowy język i nadal nazywać go C ++?
Giorgio
3
@ tpg2114 Różnica między (FORTRAN 77: Fortran 90) a (C: C ++) polega na tym, że uważa się, że Fortran 90 zastąpił FORTRAN 77, do tego stopnia, że ​​ludzie mówią: „Jeśli chcesz się uczyć Fortran, naucz się Fortran 2003 lub co najmniej 90, ponieważ teraz jest to standard. ” Nikt nie powiedziałby czegoś takiego: „Jeśli chcesz nauczyć się języka C, naucz się języka C ++, ponieważ jest to nowy standard”, ponieważ są one prezentowane jako dwa różne języki. Jak powiedziałem, konotacje mają konsekwencje.
6
PONIEWAŻ C NIGDY NIE umiera
Adel

Odpowiedzi:

13

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?”

Giorgio
źródło
Ta odpowiedź jest dla mnie najbardziej sensowna spośród wszystkich, które tu widziałem: aktualizacja języka pozwala odziedziczyć (przynajmniej niektóre) istniejącą społeczność, biblioteki itp. Pamiętam, że największym problemem Lisp jest duża liczba nieznacznie niekompatybilne dialekty, które utrudniają utrzymanie społeczności; aktualizacja istniejącego języka może być sposobem na uniknięcie fragmentacji innych społeczności w ten sam sposób.
@SunAvatar: O ile mi wiadomo, Lisp ma kilka dialektów, ale niektóre odnoszą większe sukcesy niż inne (Common Lisp, Scheme, Racket, Clojure). Za każdym razem, gdy zaczynasz nowy język, ryzykujesz, że tylko bardzo mała społeczność zgromadzi się wokół niego. W społeczności Lisp wydaje się to powszechną praktyką: jeśli ktoś ma nowy pomysł, rozgałęzia się i sprawdza, co się stanie. Dla twórców innych języków utrata społeczności nie jest opcją.
Giorgio,
@SunAvatar: Nie uważam dziedziczenia istniejących bibliotek za silny argument. Nie potrzebujesz do tego kompatybilności kodu źródłowego. Zobacz np. Jak Clojure i Scala mogą korzystać z kodu Java.
Giorgio,
1
Języki nie umierają, tylko programiści, którzy ich używają.
Evan Plaice
@SunAvatar: Istnieją również społeczności, które starają się stosować inne zasady: nazwa identyfikuje język, a jeśli część społeczności tworzy zbyt rozbieżny dialekt, używa nowej nazwy, aby uniknąć zamieszania. Patrz np. Racket-lang.org/new-name.html
Giorgio
21

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.

Inżynier świata
źródło
14
Problematyka tekstu naukowego w formacie Tex = niewiele się zmieniła. Domena języków programowania = znajdź nowe zastosowania dla nowych komputerów, jest raczej bardziej ekspansywna. Z tego samego powodu łacina nie dodaje tyle nowych słów, co angielski
Martin Beckett,
Nie sądzę, aby kompatybilność wsteczna była ważnym powodem: Scala może być łatwo zintegrowana z istniejącym kodem Java, ale nie jest to super zestaw Java. Myślę więc, że ogólnie rzecz biorąc nie jest konieczne, aby nowy język był kompatybilny ze starym na poziomie kodu źródłowego. Wystarczy mieć dobrze zdefiniowany mechanizm wywoływania starszego kodu z nowego kodu.
Giorgio
@Martin Beckett: „Problematyka tekstu naukowego w formacie Tex = niewiele się zmieniła.”: Myślę, że nie rozumiesz sedna pytania. PO nie pyta, czy powinny istnieć innowacje w językach programowania (nikt nie może zaprzeczyć, że innowacja jest konieczna), ale dlaczego stare języki są zmieniane zamiast tworzyć nowe.
Giorgio
Systemy budowane są na inwestycjach czasu, pieniędzy i wiedzy specjalistycznej (doświadczenie zdobyte w danym języku). Nowe prace kosztują znacznie więcej niż prace konserwacyjne (we wszystkich trzech kategoriach). Bez ulepszeń języka i platformy ogólnie koszty utrzymania rosną, a następnie koszt nowego systemu jest bardziej atrakcyjny, a autentyczne ponowne umieszczenie aplikacji COBOL na zupełnie innej platformie po raz ósmy w życiu może się nie wydawać jak już tak wiele.
JustinC,
Gdyby nie zaktualizowane standardy języka COBOL i implementatorzy narzędzi COBOL, dodając po drodze swoje własne unikalne funkcje, poprawiłoby to język i poprawiło zdolność do działania na szerszych, ogólnodostępnych, nowoczesnych platformach; aplikacja nie przetrwałaby 60 lat. Podczas gdy koszty względne z pewnością wzrosły w późniejszym okresie jego życia, z powodu rosnącego niedoboru wiedzy specjalistycznej, wysiłek w całości kosztował dolara w porównaniu do zwykłego przepisywania, gdy pojawił się język chwili.
JustinC,
5

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.).

TMN
źródło
Jeśli więc powodem jest „wystarczająca liczba osób dbających o starsze języki”, czy powiedziałbyś, że twoją odpowiedź można sformułować jako „sentymentalne przywiązanie do istniejących języków”? Nie mówię tego pejoratywnie, po prostu próbuję zrozumieć twoją odpowiedź.
Avner Shahar-Kashtan
Nie, miałem na myśli, że języki są nadal aktywne i są używane przez ludzi, którzy chcą skorzystać z najnowszych technik. Nie sądzę, żeby ktokolwiek dodał obsługę wielowątkowości do ALGOL, ponieważ (AFAIK) nie jest aktywnie wykorzystywany. FORTRAN i COBOL są jednak nadal używane do opracowywania nowych systemów, więc ich specyfikacje językowe są okresowo aktualizowane w celu włączenia nowych technik i technologii.
TMN
1

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.)

Ben
źródło
1
Zmiany, które opisujesz w drugim akapicie, są dość nie budzące sprzeciwu (przez to mam na myśli nie tylko to, że nie mam nic przeciwko, ale że nikt nie może poważnie się temu sprzeciwić). Jeśli chodzi o lambdas, nie mogę komentować ich przydatności w C ++, ale po co zawracać sobie głowy ich dodawaniem, jeśli nie, aby zmienić sposób wyrażania algorytmów?
Och, są niezwykle przydatne. Nie zrozum mnie źle. Są najważniejszym dodatkiem w C ++ (IMO). Myślę, że nie miałem jasności co do tego, co miałem na myśli. Zazwyczaj wybiera się C ++, aby mieć bezpośredni dostęp do pamięci, deterministyczną wydajność i wysoki potencjał optymalizacji. Nie zmienia się to w przypadku najnowszych dodatków. Upraszczamy wiele innych zadań programistycznych wokół tego, dlaczego wybrałeś C ++, ale C ++ jest nadal ważny i użyteczny z tych samych powodów. Schemat jest aktualizowany regularnie, ale kod-jako-dane i lispy-ness się nie zmieniają, więc dzisiaj wybierasz schemat z tych samych powodów, co 20 lat temu.
Ben
„Jeśli chodzi o lambdas, nie mogę komentować ich przydatności w C ++, ale po co zawracać sobie głowy ich dodawaniem, jeśli nie, aby zmienić sposób wyrażania algorytmów?”: Idę jeszcze dalej: po co dodawać je do C ++ zamiast przełączać się na język, który miał je od początku?
Giorgio
2
@Giorgio Aby kontrolować funkcje pamięci podręcznej i abstrakcji w języku. Jeśli żaden istniejący język nie zapewnia obu tych języków, nie można przełączać języków bez poświęcania jednego z nich. Musisz zmodyfikować język lub utworzyć nowy.
mike30
@mike: Co rozumiesz przez „funkcje pamięci podręcznej”?
Giorgio
-2

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.

DaveM
źródło
Myślę, że myślisz o „żartobliwym”.
uliwitness,