Pytanie Zaprojektuj wskazówki dotyczące programu, który będzie uruchamiany za 25 lat [zamknięty]


Jeśli tworzysz aplikację (która zajmuje się głównie przetwarzaniem danych), która musi zostać uruchomiona teraz i być może (może nie) 10 lub 25 lat później, jakie wskazówki projektowe są dostępne dla takich aplikacji?

Obowiązują ogólne zasady: polegaj na oprogramowaniu open source i sprawdzonych platformach oraz bezpiecznych formatach danych.

Język musi być językiem wysokiego poziomu dla celów czytelności (być może jedyną opcją będzie ponowne napisanie aplikacji w ciągu 15 lat przez kogoś, kto ma niewielką wiedzę na temat oryginalnego kodu).

Pójdę do UNIX (Linux) + Python + YAML / JSON (/ CSV / tekst jawny), wszelkie wskazówki dotyczące tego wyboru lub alternatywnego zestawu narzędzi? Scheme / LIPP istnieje już od wieków i naprawdę trudno jest zepsuć podstawy językowe, biorąc pod uwagę, że wszystko byłoby samodzielne.

EDYCJA: nie zapomnij o poradach dotyczących aktualnego projektu i kodu, na przykład 2038 rok wydania!


16
2017-08-18 06:20


pochodzenie


Jeśli będzie działać tylko teraz, i ponownie za 10 lub 25 lat, możesz rozważyć jego przydatność :-) - paxdiablo
Chociaż interesujące, to pytanie tak naprawdę nie ma odpowiedzi. Pytanie wymagałoby szczegółowego określenia aplikacji uruchamianej raz na kwartał w celu zapewnienia bardziej wąskiego zakresu dyskusji. Wielkość programu określa, ile wysiłku powinno być, ale w program wieczności w porównaniu do dobrej specyfikacji. - Aleksi Yrttiaho
Przejdź do c ++, będą potrzebować kolejnych 25-tek, aby utworzyć nowy kompilator. - Luka Rahne
@ralu: zajmie to również 25 lat, aby zrozumieć błąd kompilacji szablonu dla każdego przyszłego modyfikatora :) - amit
@Aleksi - zapewniamy, że istnieje również szczegółowa specyfikacja. Lubię samodzielne specyfikacje, czyli przechowywanie danych oparte na plikach tekstowych z odpowiednio dobrymi dokumentami w nagłówkach + dobrze udokumentowany kod źródłowy + dokumentacja formalna. Nadal jestem zainteresowany tworzeniem dobrej "referencyjnej implementacji" paxdiablo - będzie ona uruchamiana częściej, ale na jak długo nie jest znana z góry. - Martin Paljak


Odpowiedzi:


W rzeczywistości wymaganiem nr 1 byłoby "użycie popularnego języka z formalną specyfikacją International Standards Organisation". Jest to o wiele ważniejsze niż jakakolwiek inna rzecz, o której wspomniałeś. ("Open Source"? Proszę ... Istnieją tysiące programów z domeny publicznej z lat 80. i 90., których uruchomienie byłoby dziś prawie niemożliwe).

Na przykład, jeśli kodujesz sztywno do specyfikacji C99 lub C ++ 98 lub C ++ 03 lub nawet C ++ 0x, kursy wynoszą w przybliżeniu 99,9999%, że kompilator będzie istniał dla twojej platformy 10, 20 i 50 lat od teraz może obsłużyć twój kod z zerowymi zmianami. Jest to prawdopodobnie najbardziej przydatna rzecz w formalnej specyfikacji popularnego języka.

Kodowanie sztywno do takiej specyfikacji może nie być łatwe, ponieważ wiele nietrywialnych programów (na przykład wszystko z GUI) nie może być napisane w 100% przenośnie.

Ale to wciąż jest miejsce, od którego zacznę. Wprowadź jak najwięcej w 100% kodu zgodnego ze standardami, a następnie odizoluj resztę (podobnie jak GUI) w modułach zależnych od platformy. Zminimalizuj rozmiar tego ostatniego, a zminimalizujesz pracę, którą muszą wykonać twoi następcy.

Darmowe narzędzia innych firm - czy coś takiego jak Boost lub coś w stylu Pythona - są świetnymi odpowiedziami na niektóre pytania, ale nie na to.


6
2017-08-18 06:49



Myślałem, że Python 3 ma specyfikację? W każdym razie, jeśli będziesz sztywno trzymać się specyfikacji C99, nie będziesz w stanie skompilować go z większością kompilatorów. - Chris Lutz
@ Chris: Nie powiedziałem "większość kompilatorów"; Powiedziałem "za kompilator ", czego właśnie powinieneś szukać tutaj." Większość kompilatorów "nie będzie istnieć od 25 lat Specyfikacja będzie, a więc coś, co ją implementuje Re: Specyfikacja Python 3, czy masz odniesienie? Numer dokumentu ISO Guido jest świetnym facetem, ale jestem pewien, że jest śmiertelny, nie postawiłbym żadnych zakładów na to, co stanie się z Pythonem podczas jego nieobecności. - Nemo
Mój punkt na C99 był taki, że będziesz miał problem ze skompilowaniem go teraz, choć bez wątpienia zadziałałoby to w przyszłości, gdy GCC się dogoni (mam nadzieję, że niedługo). W Pythonie mam wrażenie, że czytałem gdzieś, że Python 3 był ustandaryzowany, ale nie pamiętam gdzie, i nie wydaje mi się, żebym mógł znaleźć dla niego jakiekolwiek odniesienie. (Nie wierzę, że GvR jest śmiertelny, w rzeczywistości jest wszechpotężnym wężem, który starzeje się wstecz.) - Chris Lutz


biorąc pod uwagę, że dostarczysz dobrze udokumentowany kod źródłowy, zawsze mogli zoptymalizować kod, jeśli pojawi się jakakolwiek nowa technologia zgodna z twoim aktualnym kodem. Inaczej będą musieli sami go przesłać.


3
2017-08-18 06:30





Interesujący byłby okres półtrwania wdrożonej aplikacji. Domyślam się, że 10 lat wcale nie jest niezwykłe, a podstawowe aplikacje przedsiębiorstwa mogą mieć ponad 25 lat - jest tam mnóstwo aplikacji Mainframe / CICS.

Dlatego też twierdzę, że każdy poważny rozwój musi przewidywać, że wniosek będzie stosowany przez co najmniej 10 lat. Duże Enterpises może mieć politykę "Evergreening" - migracja ich aplikacji do późniejszych wersji systemów operacyjnych, baz danych itp.

Zupełnie niemożliwe jest odgadnąć długowieczność każdej platformy, więc wybierz coś, co jest dość powszechnie przyjęte i które jest w pewnym sensie (de facto lub formalnie) standardem.

Sugerowany stos jest rozsądny, Java i Spring lub Java EE też byłyby dobre.

Zwracałbym uwagę na modułowość i "otwartość" aplikacji. Kiedy mówię, że wiele aplikacji ma więcej niż 10 lat, nie oznacza to, że są one skamieniałe w tym czasie. Aplikacje zmieniają się wewnętrznie i integrują z coraz większą liczbą systemów. Te aplikacje CICS generują obecnie dane wyświetlane na urządzeniach mobilnych, które były niespotykane 20 lat temu.

Więc spójrz na interfejsy do swojej aplikacji, wybierz warstwową i modułową architekturę, która pozwala na ewolucję elementów wewnętrznych i uwzględnia nowe integracje.


3
2017-08-18 06:42





Java może być dobrym językiem do napisania. Java ma doskonałą kompatybilność wsteczną, dużą bibliotekę standardową, która ma również dobrą kompatybilność wsteczną i jest na tyle popularna, że ​​najprawdopodobniej będzie dostępna za 25 lat. Nawet jeśli java wypada z łaski, jest wystarczająco dużo języków jvm takich jak scala i clojure, które prawdopodobnie staną się na tyle popularne, aby zapewnić przetrwanie jvm i java jako produktu ubocznego.

Python może nie być dobrym wyborem, ponieważ czasami łamią kompatybilność (python 3 nie jest kompatybilny z pythonem 2).


1
2017-08-18 06:28



Gdyby to było 2 lata temu, zgodziłbym się. Wielu obecnie boi się, że wyrocznia zacznie egzekwować prawne ograniczenia używania java, więc przyszłość java przez następne 15 lat nie jest pewna: \ - amit
Tam było jeden zmiana w Pythonie, który przełamał kompatybilność w swoim 20 lat historia. Wątpię, aby w następnych 20 było jeszcze jedno. - Ferdinand Beyer
Trochę boję się Javy. Aplikacja nie zawiera żadnej nauki o rakietach, ale dekodowanie Java jest czasami trudniejsze niż przeczytanie dobrze napisanego pythona. Z drugiej strony, "po prostu kup od Oracle jako usługi w chmurze i niech martwią się ciągłością, Oracle będzie i tak za 25 lat" nie jest rozwiązaniem;) Java jest zbytnio związana ze środowiskiem komercyjnym i jest napędzana przez komercyjne interesy . Firmy przychodzą i odchodzą. Hej, Apple nie rozpowszechnia już Java domyślnie ... - Martin Paljak
Wyjątki Apple'a nie powinny być traktowane zbyt poważnie, mimo że są obecnie modne. Java będzie prawdopodobnie wspierana w taki czy inny sposób w ciągu 25 lat, podczas gdy do tego czasu mogła zostać utracona do starszego języka. Będzie wielu stypendystów w wieku 50-80 lat, którzy pamiętają heydiję Javy, ponieważ teraz są tacy, którzy mówią o COBOL i APL i tym podobne. - Aleksi Yrttiaho