Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
На чём вы бы сейчас стали писать систему, рассчитанную на то, что её потом будут использовать десятилетиями? И через N лет захотят туда что-нибудь приделать.
Например, какую-нибудь государственную информационную систему или базу знаний для какой-нибудь профессиональной ассоциации.
Вопрос не корректен, как по мне.
Задаваться нужно «какую (как?) АРХИТЕКТУРУ приложения выбрать, если продукт рассчитан на десятилетия».
Главное — архитектура.
Язык/платформа — инструмент.
Если архитектура продуманна качественно — рефакторить (он будет неизбежен со временем) и, даже, переписывать целые компоненты на ином языке — дело техники и будет реализуемо просто.
При поддержке старых продуктов обычно камнем преткновения есть кривизна Архитектуры, а не то, на чем написан продукт.
Архитектура — все.
Язык прораммирования — инструмент и есть вторичное.
На чём угодно. Такая система должна работать через API, а не быть привязанной к языку. Настоящий вопрос — это пониммание объёмов данных и нагрузки, с которыми предстоит иметь дело, плюс требования по надёжности и резервированию. От них и плясать — как именно разбивать систему на модули.
Так что пиши на обычном человеческом языке. Именно от постановки задачи зависит, будет ли система успешна или нет. А совсем не от выбранной технологии.
Напишите на джаве, а мы в пятидесятых будучи дедами 60 летними будем ее поддерживать.
Ага, 2.7
Без разницы, любая технологя устаревает и прийдется переделывать.
-
Пишите на Assembler — он точно всех переживет :))
У дедушки Кнута есть
вы не в курсе, что сам Кнут от него отказывается? переходит на MMIX, который — суровый современный RISC.
Был не в курсе, теперь знаю.
есть такой этап в разработке- называется реквайремент коллекшн. по реквайрементам определяется что это за система — ЕРП, база данных, риал тайм, эмбедед, ОС и так далее. для каждой системы есть рекомендованные языки программирования, тоесть вы обычно имеете огранниченный выбор из языков и часто уже готовых модулей в зависимости от функциональности системы. Если эмбедед — то джава или с++ или эмбедед с. Если ОС — то с++, если ЕРП — то делфи, джвава или пхп, ну и так далее. Частенько выбор языка может быть задан каким то модным трендом или личным знакомством команды именно с этой технологией. Ну и на последок существенное влияние может оказать бюджет проекта — если у вас нету денег на выделенный сан сервер где будет жить оракл и томкэто то может смотреть в сторону компьютеров попроще с пхп и майсиквел. Государственная информационная система это скорее что то типа википедии, и тогда напрашивается стек или джава-веб или пхп или с шарп-веб.
реквайремент коллекшнВам чиза наслайсить али как? ©
Можн байтсами? И смусси с айсом из ватермелона.
Я вас сильно удивлю, если скажу, что на практике технологии определяются бюджетом, системой и реквайрментами далеко не в первую очередь? Как на меня, определяющими есть: (1) упрямство заказчика («хочу VB6, а потом может быть перепишем на .net») (2) наличие свободных девов в компании по той или иной компетенции (3) «девичья» специальность тех-лида и-или архетектора, который ваяет пропоузал.
ну в данном случае они наверно и есть заказчики и тут идет выбор на чем писать что бы потом было дешевле поддерживать и кого нанять что бы все это сделал.
НЕТЪ! invisiblebread.com/...-software-engineering.png
А вообще где я работаю занимаются архивированием на микрофильмы. И тут 500 лет сохранности гарантируют. Код декодера хотят также хранить на микрофильме и там только С. Сама система в основном С++.
На каком носителе сохраняете микрофильмы, чтобы они 500 лет продержались?
Ээ на микроплёнке. Подробности про плёнку не подскажу, но её там модно тестили как-то, чтоб гарантировать.
Да только фирма, ее производящая, уже того... Кодак называлась.
Все, что больше
Я как-то больше поверю перфокартам из металлизированного лавсана.
Работал с джава проектами, которые начинали писать в 2001. Полет относительно нормальный.
Streams api. Optional. Чуть красивее чем с Гуавой.
Имхо, в рамках длительно живущего проекту, данные плюшки не перевешивают минусы.
-Переход версий это, скорей всего куча потраченного времени на совместимость библиотек и прочего.
-Это куча заинтродюсеных багов.
-Это добавление еще одного стиля кодирования к уже существующему нагромождению стилей, подходов и фреимворков — на проекте, наверняка есть код датированный 2001, который никто не трогает, потомучто есть более важные задачи.
То есть еще без дженериков сидите? Действительно, зачем что-то менять.
В этом кагбы и есть основной недостаток долгоживущих систем. Вместо клевых новых фреимворков, языков и плюшек — приходиться иметь дело с устаревшими языками и технологиями. Причем не нарефакторишся и не на переписываешся.
Проект, на котором можно работать от института до пенсии. Для тех, кому такой путь подходит.
Ой, ну только не нужно вот это отмазок слезливых придумывать. Джава код до сих пор не пользующий дженерики либо никому не нужен особо либо представляет большой риск для компании и показывает техническую несостоятельность. Думаем не только об удобстве программистов (и большей надежности кода за счет лучшей статической типизации), но и security updates, производетельности (был случай клиент быстрее перевел продакшн на java6 чем мы раздуплились в девелопменте — лучше памятью управляла, и было уже нужно), перспективами в будущем, когда все меньше и меньше будет хорошо сочетаемого железа и инфраструктуры.
Лично как-то переводил переводил немалый джава проект корнями уходящий как раз в 2001 на дженерики и дальше. И во многих других случаях без проблем рефакторится все — not a rocket science, просто элементарная аккуратность и настойчивость.
И во многих других случаях без проблем рефакторится все — not a rocket science, просто элементарная аккуратность и настойчивость.
Используемая тогда стратегия, с которой я полностью согласен — выждать момент, когда с одной стороны новая версия достаточно стабильна, поддерживаема, и имеет достаточно программистов на рынке, с другой — такой переход с внезапными запарами и багами не причинит существенных потерь для бизнесу.
Код базу же приводить к сответствию — только по мере надобности, когда идет работа над этим модулем, и его можно безболезненно отрефакторить и оттестировать.
В таком режиме код база разтягиваеться — наверняка на проекте дето есть код родом из 2001 где нет никаких дженериков.
P.S. java отставшей версии в рамках дискуссии — плохой пример т.к. в принципе не лучше снапшота любой другой технологии в конкретный отдельный момент. Чем java сильна — это как раз развитием без радикальных разрывов.
Жаба сильна тем, во первых, что как и в 2001, так и сейчас, можно найти программистов способных поддерживать это. Во вторых тем, что код база пройдя церез целые кучи джунов, и синьйоров считающимися только со своими взглядами на код — оно продолжает работать и не падает с сегфоултами на каждый чих.
Haskell, под Linux, разбиение на независимые компоненты и open source.
Если данные будут отделены от бизнес логики а она от представления, то на обычном языке нужно описать формат данных и бизнес логику, и поддерживать описание в актуальном состоянии. То есть языки программирования пофик.
А если все будет слито и без документации, то через 10 лет туда все равно ничего не довписать, и систему выбросят, наковыряв из неё данных, для перемещения их в новую.
Вторым доводилось заниматься лично. И на чем она была написана тоже пофик
Насчёт описания — совершенно верно. Документация — это святое, если проект большой, серьёзный и долгоиграющий.
На граните :)
Слехка настораживает подход: во времена Agile, когда мы успешно и регулярно переписываем то, что написали буквально несколько месяцев взад, ставить задачу написать систему на десятилетия ... у меня есть единственная догадка, что это может быть за система: бортового управления космического зонда типа New Horizons. Во всех остальных случаях (даже для корабля, который слетал на Марс и вернулССо) ее must периодически обновлять.
Я бы писал на С++ и DB .. просто в силу своих умений :8) Я присоединюсь к мнению, что главное — достаточно близко угадать со scalability, maintainability и еще как минимум дюжину параметров того, что называется system quality. От языка мало что зависит. Тут уже было упоминание про 50 лет Фортрану, так вот: примерно в 2009 я с удивлением убедился, что одна крупная, но государственная, контора до тех пор еще пользуется графическим (!) приложением, которое я им наваял на Фортран Дубна (кажеЦЦа) в условиях гиперинфляции в 1992 году.
на Фортран Дубна (кажеЦЦа)
Для БЭСМ-6?
БЭСМ-6 и Фортран-Дубна — это была основная работа :) а халтурка писалась на персоналках уже. Библиотека Графор-G, кажецца, нипомню (
Микросервисы — наше все.
Толстые клиенты, REST (которому скоро, кстати, 20 лет), в крайнем случае SOAP (а ему — 18).
И главное — компонентный подход, если другие особенности системы не требуют монолита.
Микро не микро, но согласен. Разделение на сервисы, которые можно потом будет независимо друг от друга допиливать и перепиливать.
у микросервисов есть хроническая проблема:
дублирование кода сервера-клиента, на разных языках.
а если код общий, для разных сервисов и клиентов, то возникает вопрос — а чем монолитное приложение не устраивает? ведь после изменения общего кода, придется пересобирать все зависимые приложения и рестартовать их.
REST, SOAPвозникли из свойств транспортного протокола — HTTP и свойств нью-терминала под названием веб-браузер, а не из-за бОльшего удобства разработки ПО.
Я думаю все зависит от подхода и качества архитектуры. Имхо, у сервисов больше преимуществ, чем недостатков. Монолит выгодно использовать когда есть жесткие требования к быстродействию.
Имхо, у сервисов больше преимуществ, чем недостатков.смотря для каких задач.
Я думаю все зависит от подхода и качества архитектуры.а также от пряморукости программистов, ..., ... и прочие бла-бла-бла.
идея микросервисов родилась под давлением требования динамического горизонтального масштабирования.
а если не нужно НИ динамическое, НИ горизонтальное масштабирование — то на кой? в чем преимущество микросервисов для создания — сложного продукта?
без общих слов только.
дублирование кода сервера-клиента, на разных языках.Это не проблема, а прямое следствие разбиения системы на независимые компоненты.
если функциональность общая, то «компоненты» будут — зависимы.
хоть она и повторяется на разных ЯП.
потому что исправление функциональности в одной компоненте на языке Х, потребует внесения изменений и в компоненте на языке Y.
не имеет значения способ зависимости, важно что реализации функциональности требуют изменений, при изменении в одной из них.
то есть, дублирование функциональности это никак не разбиение системы на независимые компоненты, а точно наоборот. либо это не компоненты, а — сервис реализованный в виде набора — микросервисов.
Если бизнес-логика меняется в одном компоненте, то и во всех компонентах, которые с ним взаимодействуют, могут потребоваться изменения. It’s perfectly normal.
это не нормально даже для монолитного приложения.
а уж разбивать приложение на микросервисы, да на разных ЯП — тем более.
есть причины по которым приходится и денормализацией таблиц заниматься, и размазывать бизнес-логику между хранимками, сервером приложений и UI.
но стремится то нужно — в другую сторону.
не имеет значения способ зависимости, важно что реализации функциональности требуют изменений, при изменении в одной из них
Шо-то мне сразу вспомнилась такая вещь, как инкапсуляция. :-)
она не про то.
разбивая приложение с общим кодом на микросервисы — мы никак не уменьшаем связанность, зависимостей частей кода.
создавая приложение на разных ЯП, с общей функциональностью — тоже самое, связанность, зависимость этих частей не уменьшается.
так зачем разбивают?
ответ — посмотрите откуда они пришли.
и вникните в то, зачем(с какой целью) они там родились.
подсказка:
RDBMS столько лет всех устраивал. что за причина развития NoSQL?
RDBMS столько лет всех устраивал. что за причина развития NoSQL?
Детальный пример можете найти в книге Tom White «Hadoop. The definitive guide», почти в конце главы «HBase». Там разобран случай, как ради производительности настраивали и допиливали PostgreSQL, пока наконец не пришли к использованию HBase.
Так я как бы в курсе, раз упомянул как подсказку.
Сформулируй обобщенно проблему, и причину такого выбора.
А затем примени это обобщение к истории микросервисов.
Примеры долгоиграющей системы?
Реестр прав собственности. Данные всех переписей населения. Центральный банк страны (эмиссии денег, номера купюр, вот это всё). Учёт военного имущества. База знаний какой-нибудь академии наук.
Шо-то мне не вериЦЦа. Как эти данные перекочевали
Скажу крамольную вещь. Самый древний из ныне живущих языков — бейсик (старше, чем Си, живее, чем фортран). Правда, он сильно изменился со временем, но в принципе на любом диалекте любой более-менее опытный программист начнет писать практически сразу. То есть даже если сейчас обычному программеру дать исходник, написанный на каком-нибудь мертвом бейсике под DOS, сильных проблем не возникнет. Поноет, поплюется, но разберется.
сильных проблем не возникнет.
Особенно глядя на всякие POKE 24537, 11 :sarcasm:
Сейчас такие времена что сложно представить систему работающую десятилетия. Все меняется очень быстро — востребованность, требования, технологии, подходы. Вполне вероятно что проще будет потом переписать какую-то часть, чем пытаться адаптироваться под новые реалии. Так зачем тогда загадывать на десятилетие вперед?
Ну и как уже написали, разбить все на микросервисы, чтобы удобнее было выбирать технологии под конкретные задачи и не сильно заморачиваться насчет дизайна внутри микросервиса — проще будет переписать.
Концепция микросервисов не существует достаточного периода времени что бы показать свою состоятельность. Так же точно ранее все упирали на SOA. Я лично вижу здесь очевидную огромную проблему с поддержкой большого количества различных сервисов написанных на различных технологиях(исходя из принципа оптимальности технологии для решения той или иной задачи). Стоимость владения возрастает. Или нет поддержки.
Да, и кстати, когда количество сервисов переваливает за 20 иметь их все работающими одномоментно становиться близким к счастью. А если не работает-см. выше про поддержку. Где то в воздухе витает фраза про преждевременную оптимизацию и пахнет «адом dll».
когда количество сервисов переваливает за 20 иметь их все работающими одномоментно становиться близким к счастью
Для этого есть системы мониторинга.
Мониторинг на русский язык переводится как наблюдение.
Вы знаете что не работает, дальше то, что?
Опять люди, кто-то в отпуске, а кое где и разработчиков тех уже нет, и вообще внезапно вместо привычной Java — node.js+Apache Flink, целесообразно же кому-то было.
Вы знаете что не работает, дальше то, что?
А дальше — чинить.
Какие-то ещё варианты?
Никаких. Вообще. У вас нет доступа, у системы нет разработчиков и был один потребитель-вы и ваше приложение. Система сломалась-ваши проблемы,...сь как хотите. Реальная ситуация.
Вот так и иметь дело со старым legacy, которое либо не взяли вовремя под контроль (документированием и рефакторингом), либо вовремя не заменили на более новую систему.
Подождите, подождите. Это не legacy. Это вполне современный сервис, скажем так. Просто так сложилось.
Сейчас такие времена что сложно представить систему работающую десятилетия.Элементарно — любая большая ERP, например. Если умудрились не зафейлить внедрение (что само по себе почти подвиг), и начали пользоваться, то это на десятилетия. Потому что через пару-тройку лет система обрастает самодельными костылями, и не то что перейти на что-то новенькое и мимимишное, но даже просто обновить версию системы — уже нуегонафик. «Работает — не трожь», и все такое...
Разбить на микросервисы и писать на том, на чем удобно решать ту или иную задачу.
50 лет хватит?
cerncourier.com/cws/article/cern/30873
Неплохо. Но хотелось бы, чтобы выбранный язык программирования не был вытеснен на задворки открытого IT-рынка в ходе жизни проекта. Как это произошло с тем же Fortran’ом, например.
Получается, что безопаснее всего писать на C++. Он, предположительно, бессмертный.
Ещё LISP, под вопросом. С одной стороны, далеко не mainstream. С другой стороны, жив с
И это выводит на мысль о JVM, а там и до мыслей о «Typesafe stack» близко. Надо только понять, можно ли быть уверенным в том, что JVM — это, условно говоря, навсегда (как C++) или нет.
LISP — достаточно нишевый.
То что C/C++ остался как язык — ни о чем не говорит. Он достаточно низкоуровневый, и при обновлении хост-систем вы скорее всего столкнетесь с определенными трудностями. Да и то, что на нем делают сейчас только по синтаксису похоже на то что в нем было 30 лет назад.
Microsoft Excel.
«Если что-то невозможно автоматизировать с помощью Excel, то это невозможно автоматизировать в принципе» ©
Excel шикарен для обычных расчетов. Но если пытаться реализовать в нем что-то хоть сколько-нибудь сложное, придется лезть в макросы. И утонуть в болоте Visual Basic for Applications.
И утонуть в болоте Visual Basic for Applications.писати на ньому великої проблеми нема.. та й працюватиме «вічно», а от пробувати розібратись що там вже написано кимось — ось тут легше застрелитись :)))
Был я на семинаре некого гуру алготрейдинга. Он свои стратегии программировал в Excel. Когда он демонстрировал их «работу», я не смог сдержать смех. Гуру оправдывался, говорил «но оно же работает». Большинство присутствующих трясло гривой и говорило — «да, да, конечно». На второй день семинара гуру сказал, что таки решил изучить / использовать С#.
Но если бы вы сходили не на семинар к гуру, а на деск к трейдерам, увидели бы легко ексель рядом с блумбергом ) да, иногда подключаемые модули туда (в основном чтобы считать что-то заковыристое или получать/отдавать данные)
В программу семинара посещение деска не входило.
Ну а гуру...
Можно конечно приделать к телеге мотор, и проехаться по родному селу.
Может быть кто — то из однослельчан даже захочет прокатиться, и скажет «Молодец!».
Но не надо на телеге на автомагистрали выезжать.
Там мерседесы ездят.
Если веб — то конечно же php, просто не обновляйте версию на серваке. :)
Это полная противоположность тому, что я бы хотел. :-)
Я надеюсь, автор это с юмором написал. Made my day.
Да, уже проверенно работают по 40 и более лет системы на нем ))
JavaScript! Я до сих пор могу открыть свою первую игру в пятнашки, написанную лет 10 — 12 назад под IE 5.5!
Erlang, Lisp или Haskell
Erlang — уже хз сколько лет используестя в телекоммуникациях и заточен под отказоустойчивые высоконагруженные системы (и походу проги на эрланге расчитаны на то, чтобы работать чуть ли не годы).
Lisp — один из старейших языков (наравне с фортраном).
Haskell — основному стандарту хаскеля — Haskell98 уже больше 15 лет насколько понимаю. Ну там были потом улучшения (стандарт 2012 кажись), но вроде не настолько существенные, чтобы говорить о том, что язык от этого сильно изменился.
P.S. я бы еще предложил язык Forth как пусть редкий и бородатый, но вполне интересный и ИМХО годный язык (по которому вроде даже какие-то конференции проводятся) и вполне может пойти под какую-нить
государственную информационную системуибо хрен кто взломает, кроме разве что магистра Йоды))
P.P.S. ну и еще для
базу знаний для какой-нибудь профессиональной ассоциациидумаю может подойти Prolog)
И через N лет захотят туда что-нибудь приделать.Їх задовбе вже на етапі пошуку спеців, і вони перепишуть систему на якомусь похапе.
а некоторые стартаперы на эрланге делают так (по крайней мере я такое слышал): берут каких-нить похапешников и учат их эрлангу (насколько я слышал научиться писать код на эрланге для продакшена можно за две недели).
хотя если перепишут на похапе — пусть переписывают, если знают как, и если оно будет нормально работать)
ну не знаю... в разных источниках читал слышал, что эрланг реально выучить за 2 недели для того, чтобы худо-бедно писать код для продакшена под руководством более опытного эрлангера насколько я понимаю) насколько данный код будет быдлокодерским — судить не берусь, но я как-то смотрел немного эрланг — язык ИМХО, довольно простой, и думаю, если у похапешник не туп как пробка, то вполне может осилить за пару недель базу эрланга и понять концепции функциональщины. А вот писать код на уровне джедая двух недель действительно мало, но описаная схема делается с расчетом на то, что изначально есть несколько челов, хорошо зхнающих эрланг, которые и обучат похапешников писать эрланговский код и будут их контролировать, а также следить за проектированием и прочим.
а так — смысл начинать проект на ЛЮБОМ языке, если ЭТОТ ЯЗЫК изначально никто толком не знает) лучше действительно просто набрать пхпшников и писать все на пхп)
плюс поиск опытного эрлангера, который захочет ввязываться в обучение похапэшников, займет больше времени, чем поиск целой команды джава господ каких-нить + опционально релиз этими самыми господами MVP.вообще-то я говорил о том варианте, когда выбор эрланга предопределен уже, и что есть эрлангисты, которые согласны обучать пхпшников (или кодеров на др. языках) кодингу на эрланге.
Несколько взаимоисключающие параграфыцитирование вырвано из контекста. Я не говорил про то, что десятилетиями будет использоваться код написанный начинающими эрлангистами.
Развешо есть инвестор, который хочет из своего кармана сильно заплатить за то, что команда хочет пописать на хаскеле или лиспе и в итоге получить результат, который будет ничем не лучше написанного на каком-нить мейнстримном языке + проблемы с набором персонала.
если это будут хорошие программеры на лиспе или хаскеле — то он будет не лучше и не хуже кода написанного программерами на джаве такого же уровня.
Поэтому все зависит от того, какими программистами стартапер изначально располагает. если он располагает изгначально только джава-программерами, то и писать будут на джаве, будут в распоряжении программеры на лиспе — могут выбрать и лисп.
Ruby. Думаю, це та мова, яка вже задала тренд для мов майбутнього.
Концептуально красив, на деле хипстоговно. Весь крупняк им наигрался и выкинул на свалку истории. Сейчас и ваканции стали подтягиваться вниз.
Вопрос не корректен, как по мне.
Задаваться нужно «какую (как?) АРХИТЕКТУРУ приложения выбрать, если продукт рассчитан на десятилетия».
Главное — архитектура.
Язык/платформа — инструмент.
Если архитектура продуманна качественно — рефакторить (он будет неизбежен со временем) и, даже, переписывать целые компоненты на ином языке — дело техники и будет реализуемо просто.
При поддержке старых продуктов обычно камнем преткновения есть кривизна Архитектуры, а не то, на чем написан продукт.
Архитектура — все.
Язык прораммирования — инструмент и есть вторичное.
Архитектура неразрывно связана с языком и его выразительными средствами. Как бы ни был крут архитектор, ось на Ruby или AAA—игровой движок на эрланге не создать.
Архитектуру можно реализовать на любом mainstream’овом языке.
15 лет назад рулил Perl. Потом он вдруг стал постепенно уходить со сцены.
И какая бы ни была замечательная архитектура, на полу-мёртвом (или экзотическом) языке реализовывать её не целесообразно. Потому что негде будет искать спецов по поддержке.
до сих пор набирают спецов на коболе
находят же
Ага, одного на много тысяч.
Сравните усилия, необходимые для поиска специалиста по Cobol и по C++. Поиском кого из них вы бы предпочли заниматься, если окажетесь на роли tech lead? Не думаю, что вам был бы в радость такой «challenge», как поиск специалиста по Cobol, когда вокруг более-менее хватает специалистов по C++.
UNIX :)
Они вытесняются ближайшими родственниками (в основном Linux), но в сумме происходит только расширение.
На десктопах, пока живы Intel-based Mac, FreeBSD будет с нами.
Я это пишу из-под FreeBSD. Но факт то, что я не буду её ставить для серверов во всех своих задачах :(
Не для данного аспекта.
У нас складская WMS написана лет 20 назад на языке RPG и теперь прикрутить на нее что-то более менее современное достаточно сложно. Есть умельцы, которые это делают, но с большими проблемами.
Также нужно помнить о том, что люди, которые работают с этой системой и на этом языке на дороге не валяются и их нужно холить, лелеять и растить внутри компании.
Да. Именно поэтому и была поднята эта тема.
Могу судить по своим приложениям. Если система(и требования) не меняются, то можно написать на чем угодно. Главное, чтобы не было глюков из-за увеличения базы или изменения конфигурации.
Тут могут быть другие подводные камни. Когда-то были популярны десктопные приложения, потом перешли на веб, теперь на использование мобильных устройств. Или у вас программа заточена под Windows, а в компании перейдут на Linux. Тут есть много вариантов.
Поэтому долголетие программы скорее зависит от долголетия окружения.
Когда-то были популярны десктопные приложенияКогда-то было популярно мечтать о том, что всё будет на вебе, десктопных приложений не останется. И писать неюзабельные IDE и клоны фотошопа в облаках. Вроде бы эта тенденция пошла назад. Наигрались, поняв что даже Evernote и email гораздо менее удобны в веб-обертке, чем их нативные собратья, что видео лучше смотреть в хорошем плеере в FullHD а не на Youtube, что Skype и Viber никогда не создашь в браузере с приемлемым качеством. О профессиональных продуктах наподобие САПР, ГИС, видеоредакторов и т.д. и говорить не стоит.
На чём вы бы писали систему, рассчитанную на десятилетия использования?
НА КОЛЕНКЕ :):):)
С/С++ асемблер. они вечны
x86-32 уже уходит. ARM вытеснил весь младший сегмент.
C изменяется, C++ изменяется, оба местами несовместимо.
что значит изменяется? они вечны и могу пспорить они будут вечны еще минмум лет 50. а асемблер — нет смысла говоритиь
что значит изменяется?
Что старый код не будет собираться новыми версиями.
могу пспорить они будут вечны еще минмум лет 50.
И точно так же каждые лет 15 будет несовместимое изменение.
а асемблер — нет смысла говоритиь
Это согласие или возражение?
ну для этого естественно нормальные люди замораживают версию языка, делают бекапы программ и компиляторов в которых собирают и тд...... не вечна даже вселенная, ели смотреть как вы. а асемблер изменяется как на меня медленее всех.....я смотрел код 30 летней давности, потом в универе писали, смотрю что пишут сечас — изменения минимальны.
нормальные люди замораживают версию языка, делают бекапы программ и компиляторов в которых собирают и тд
Даже не смешно. Завтра сменится система (хотя бы придёт новая версия), и окажется, что старых компиляторов под неё нет, или они не учитывают что-то принципиальное.
асемблер изменяется как на меня медленее всех.....я смотрел код 30 летней давности, потом в универе писали, смотрю что пишут сечас — изменения минимальны.
30 лет назад это
А перейти в 32 бита — поменять существенную часть логики. А в 64 — ещё поменять. И весь старый код идёт к лешему.
Кстати, даже те лабораторные в винде новее XP не запустите штатно —
Даже не смешно. Завтра сменится система (хотя бы придёт новая версия), и окажется, что старых компиляторов под неё нет, или они не учитывают что-то принципиальное.
Практически все долгоживущие системы сейчас живут эмуляцией байт-кода. System/360, (S)NES, Spectrum, Atari, Amiga, DOS. Машинный код (ассемблер) замораживается и эмулируется на новых системах.
Инструмент, если он есть, тоже замораживается. Нужно собрать код на Turbo Pascal-е? TP в DOSbox-е. Или пишется специнструмент на новой системе.
Единственное хорошо известное исключение — unix.
Практически все долгоживущие системы сейчас живут эмуляцией байт-кода. System/360,
Уже не адекватно.
en.wikipedia.org/wiki/Z/Architecture
Все прикладные программы для S/360 исполняются без изменений. (Системные — тоже, после замены пары констант типа размера страницы и адаптации под
Разумеется, можно исполнять код от S/360 в эмуляторе типа Hercules — и это даже одобряется, если вам достаточна производительность типа 100 уровней
(S)NES, Spectrum, Atari, Amiga, DOS. Машинный код (ассемблер) замораживается и эмулируется на новых системах.
Первую не знаю, а про остальные — реальное использование таких установок ограничивается ностальгией по старым играм. Особенно сейчас, когда нормальный
Единственное хорошо известное исключение — unix.
Нет, не единственное. В реальности таких 99.999% от того, что используется хоть как-то коммерчески. Сюда входит и Unix (да, перекомпиляция под новые версии дистрибутивов — жёстко рекомендованный путь), и MS Windows (вы уже с трудом
en.wikipedia.org/wiki/Z/Architecture
Это тоже эмуляция, в том смысле, что оно выполняет байт-код от старого оборудования на новом. Вроде того, как современный Core i* эмулирует x86, но лучше сделано.
Иначе это надо считать очень живучим программно-аппаратным комплексом.
Ну так это и нельзя назвать «использованием» в том смысле, как в заголовке темы.
Тогда надо вспоминать примеры использования в смысле заголовка темы. Кроме тех машин IBM, и возможно DOS, мне сложно что-то вспомнить. Почти всё переписывают.
Нет, не единственное.
Имелась в виду перекомпиляция под новую систему, а не выполнение байт-кода на эмуляторе.
Есть ещё одно, но с оговорками — FORTRAN, который до f90.
Это тоже эмуляция, в том смысле, что оно выполняет байт-код от старого оборудования на новом. Вроде того, как современный Core i* эмулирует x86, но лучше сделано.
Формально это верно, но по факту совершенно бессмысленно, хотя бы потому, что S/360 изначально запускалась как линейка моделей, в которой самые младшие могли чуть ли не всё исполнять микрокомандно, а старшие умели конвейер (по тем временам — супердостижение), а в
Иначе это надо считать очень живучим программно-аппаратным комплексом.
А именно так оно и есть. В чём-то, конечно, за счёт цены (ты дешевле, грубо говоря, 500k$ её не купишь; но за эти деньги ты получишь поддержку такого уровня, что другим и не снилась). Но в первую очередь за счёт очень грамотного развития, по сравнению с которым путь того же x86 выглядит совершенно кошмарно — как будто бригада пьяных грузчиков, не разбирающихся в предмете, делала выбор в половине случаев в сторону решения, где находилось одно знакомое слово, а в половине вообще бросанием игральных кубиков.
Тогда надо вспоминать примеры использования в смысле заголовка темы. Кроме тех машин IBM, и возможно DOS, мне сложно что-то вспомнить. Почти всё переписывают.
Именно. Потому крайне сложно ответить на вопрос автора темы. Есть несколько очевидных вариантов, но очень специфических: тот же LISP, который за счёт предельной ориентированности концепции способен пережить столетия; Haskell, который приближается к нему, хотя и имеет странные решения; но они оба предельно высокоуровневые и потому не могут эффективно реализовывать нижние уровни, и поэтому туда не расширяются. И даже они не переживут изменения типа «всё переписать с пиксельной графики на шейдерную», придётся менять алгоритм. А на более низких уровнях пляска концепций может быть такой, что и 10 лет — нереальный срок.
Поэтому для меня исходная постановка вопроса превращается в «попытайтесь объяснить, что из технологий данного момента имеет больше всего шансов прожить», но с отрезанием верхнего уровня. И вот тут уже становится совсем путано.
Имелась в виду перекомпиляция под новую систему, а не выполнение байт-кода на эмуляторе.
С DOS не получится.
Есть ещё одно, но с оговорками — FORTRAN, который до f90.
И да, и нет. Опять-таки это случай предельной ориентировки под задачу. Но стоит только поставить вопрос за пределами предыдущей области мышления — типа «а как вы поможете распараллелить это действие для полной загрузки нашего
Потому крайне сложно ответить на вопрос автора темы.
Да, поэтому и интересно посмотреть на системы, которые пережили десятилетия. И ответ напрашиватеся «да на чём угодно», потому что нет очевидной зависимости.
Варианты долгой жизни пока такие:
1. Полное сохранение рабочей среды. Либо эмулятор (DOS), либо выпуск совместимого железа (S/360).
2. Сохранение совместимого языка под новое железо (c/unix, fortran)
3. Стандартизация данных, постоянное переписывание модулей на современных языках / под современное железо.
Все три варианта работают. Более того, если подумать, а что вообще умерло? Совсем?
а как вы поможете распараллелить это действие для полной загрузки нашего24-ядерного процессора?
Против такого только совместимость данных. И переписывать всё под современные технологии. ФП вроде подаёт какие-то сигналы в этом направлении, но пока не очень внятно.
тот же LISP, который за счёт предельной ориентированности концепции способен пережить столетия
А можно пример чего-нибудь долгоживущего на Лиспе?
Я могу вспомнить только macsyma/maxima, и там чего-то переписывалось при переносе с maclisp’а на common lisp. Плюс проект очень специфический.
Все три варианта работают. Более того, если подумать, а что вообще умерло? Совсем?
Не согласен. Только 2 и 3.
Критерий «умерло / не умерло» — востребованность на открытом рынке труда, некий нечёткий порог. С учётом динамики изменения востребованности за последние лет
Это если искать по ключевым словам в резюме. Сколько времени нужно среднему
Сложности с поиском будут, но совсем исключать такой вариант я бы не стал. Не нужно недооценивать обучаемость ITшников.
Сколько времени нужно среднемуC-нику, чтобы освоить Fortran? Неделя? Два дня?
Это авантюризм. Я считаю, что такой подход не годится.
А можно пример чего-нибудь долгоживущего на Лиспе?Emacs написан на диалекте лиспа например)
ru.wikipedia.org/...D.D0.B5.D0.BD.D0.B8.D0.B5 — Лисп (пункт «Применение») (на википедии)
З.Ы. если иметь ввиду сугубо Common Lisp (стандарт как никак), то... ru.wikipedia.org/wiki/Common_Lisp — в самом низу под катом «Common Lisp» там есть перечень программного обеспечения, написанного на коммон лиспе) (а также перечень реализаций самого коммон лиспа) Правда не знаю, насколько оно долгоживущее)
Emacs написан на диалекте лиспа например)
Emacs написан на C и внешнего компилятора лиспа не требует вообще. Портировать, в случае чего, прийдётся код на C.
То же касается AutoCAD и всех примеров из wru:Лисп.
Maxima исключение, там базовая программа на CL.
ну википедия выдает, что там С и Emacs Lisp, т.е. лисп в емаксе таки есть. (Кэп)
«Бо́льшая часть Emacs реализована на Emacs Lisp.» © ru.wikipedia.org/wiki/Emacs_Lisp
А вот насчет прог написанных исключительно на лиспе, то наверняка есть аналоги рельсов или джанги, которые юзают фанаты коммон лиспа, если хотят забацать веб-апликуху на лиспе)
если же имеется ввиду сугубо десктопный или аппаратный софт, то «чистый» лисп (т.е. лисп без использования С/С++) если не ошибаюсь мало подходит. Ибо десктопных прог, написанных исключительно на одном лиспе я не знаю.. может спецы по коммон лиспу назовут такие)
Maxima исключение, там базовая программа на CL.ну вот — хотя бы одна прога написанна исключительно на лиспе)
перечень реализаций самого коммон лиспа
Это минус Lisp’а.
То есть уже и договорились вроде бы про стандарт, назвали его Common Lisp, — а нет, и тут надо было зоопарк реализаций развели...
тут думаю фишка в том, что насколько я понимаю реализации самого коммон лиспа скорее всего различаются друг от друга дополнительными библиотеками/макросами, написанных фанатами той или иной реализации. Ну и платформой, на которой написан тот или иной лисп (Java, LLVM, etc). Т.е. скорее там разница в дополнительных библиотеках, а базовое ядро языка (синтаксис, типы данных, конструкторы функций и т.п.) во всех этих GNU CLisp, Corman CL и прочих коммон лиспах одинаковое.
т.е. если например, MacLisp отличался от emacs lisp (походу, насколько я понимаю емакс лисп счас юзается только в емаксе благодаря популярности последнего), то Corman Lisp от GNU Clisp (как я понимаю) почти ничем не отличается за исключением каких-то дополнительных библиотек, идущих из коробки. Если выучил Corman Lisp, то считай что знаешь и GNU CLisp (только надо изучить те ньюансы типа во что он может компилировать и т.п., которые отличают один диалект от другого).
Реально старый C, до-ANSI, это сейчас как early modern english. Вроде слова знакомые, но перевод не помешает. BSD-шный код первой половины
С другой стороны, код начала
C/C++ - да. Склоняюсь больше к этому.
Assembler — слишком низкоуровневый, и может быть своя специфика для разных процессоров.
C/C++ - да, согласен с согласием. Assembler — нет, но по другой причине, нежели низкоуровневость. Очевидно потому, что нет такого языка. Это собирательное семейство разных языков, под каждую архитектуру свой.
Так более строгая формулировка. Согласен, да.
Разбил бы на сервисы и их писал на разных стеках. мелкие и средние сервисы проще переписывать. Ну и да — использовать только open-source решения.
умирают опен сорс сильно быстро умирают
Например, какие быстро умерли ?
Смотря какие.
Есть корпоративный open source. Он во многих случаях живет достаточно долго.
Исходники главное не «потерять» и документацию адекватную писать, а то и через год никто не захочет пользоваться.
С++ еще не было? тогда С++!
Лет десять назад я так надеялся, что ему на смену прийдет какой-нибудь нормальный достаточно низкоуровневый и высокоуровневый одновременно язык.
Зовсім недавно з’явився Rust, який на цю нішу підходить. Тільки що писати щось серйозне і надовго на ньому ще дуже рано.
Ага, а еще раньше Object Pascal, D, Vala, Go и ни один пока не вытеснил С++ с его ниши. Так что не факт что и Rust-у это будет под силу.
Звичайно не факт, хоча б через інерцію і кількість існуючого коду.
Але у всього цього списку були об’єктивні причини для провалу (Object Pascal — досить жорстка і обмежуюча мова, D — трохи «покращений» С++ із важко відв’язуваним GC, Vala — суто для GTK/Gnome, Go — ті самі проблеми із GC і загальна дубовість).
В ніші Manual memory management + memory safety + високорівневість Rust поки що єдиний. Тепер питання за ком’юніті та підтримкою компаній (Мозілла все-таки відома компанія).
Go пока рано списывать ИМХО. Хотя его ниша наверное не точно поверх С++ - скорее между С++ и Java/.Net
Вообще смешно смотреть, как народ в данном вопросе рассматривает плюшки языка.
При долгосрочном планировании, плюшки языка — вообще побоку.
Гораздо важнее тайм то маркет, и банальная возможность найти программистов через 10 лет.
На джаву вы через 10 лет программистов найдете, на це++ - тоже.
На Раст — это всеравно что играть в лотерею.
Я відповідав на “ему на смену прийдет какой-нибудь нормальный... язык”.
писати щось серйозне і надовго на ньому [Rust] ще дуже рано.
Вы сейчас часто правите скрпиты
Или это был тонкий сарказм?
Wordpress?
И через N лет захотят туда что-нибудь приделать.это в смысле десятилетия будут пользоваться и ничего не менять или все время менять включая через эти большое N лет? Если второе — то обычная себе легаси система, имя которым легион. Если первое — смотрим что уже достаточно долго, широко используется особенно в консерваторах (типа банков). Джава, например, достаточно консервативна.
ух, не ожидал, что кто-то эрланг упомянет)
Таки какие требования? Сколько юзеров? Какие use-cases? Есть ли ограничения по latency, performance? Обьем данных?
Каждая система уникальная и имеет свои уникальные требования. От них и пляшут.
Но вообще рекомендую почитать о msdn.microsoft.com/...117.aspx#DomainModelStyle
Не обязательно строить в domain model стиле, но там есть полезные понятие как bounded context, subdomain и т.п. Плюс в книжках по DDD дается много советов как орагнизовать взаимодействие между различными модулями в приложении.
Юзеров — много, нагрузки — большие. :-)
Идея пока в довольно абстрактном состоянии, чтобы выдать такую конкретику.
На чём угодно. Такая система должна работать через API, а не быть привязанной к языку. Настоящий вопрос — это пониммание объёмов данных и нагрузки, с которыми предстоит иметь дело, плюс требования по надёжности и резервированию. От них и плясать — как именно разбивать систему на модули.
Так что пиши на обычном человеческом языке. Именно от постановки задачи зависит, будет ли система успешна или нет. А совсем не от выбранной технологии.
рассчитанную на десятилетия использования?а такие разве бывают?
Если нужно действительно что-то на десятилетия, то вариант только брать заточенный под задачу Аппаратно-Программный Комплекс (АПК), либо разрабатывать свой, если готовых подходящих еще нет. Принцип такой же, как и при построении Global Distribution System (GDS), Picture Archiving and Communication System (PACS) и им подобных.
Любые чисто software решения устареют уже в течении первого, в редком случае второго десятилетия. Тут лучше не закладываться больше, чем на
И запчасти из железа только, потому что дерево ссыхается а пластик на морозе крошится.
в этой стране государственные информационные системы обычно на шарпойнте левой ногой делают
У Микрософта раз в
Поэтому для ультра-долгосрочных проектов .NET не подходит.
скоро .NET либо заменят новой технологией, либо изменят до неузнаваемости.а екзешники і ліби з дотнету 2.0 як запускались, так і продовжують запускатись :))
Классический асп c 1996 — по 2021 (25 лет, Карл!)
по 2021 (25 лет, Карл!)тут або час виглянути у вікно, і подивитись на дату, або зняти шляпу нострадамуса....
Ога, а тем временем к дотнету сейчас кроссплатформенность прикручивают.
тем временем к дотнету сейчас кроссплатформенность прикручивают... уже лет 10 как. Результат — так себе.
вовревмя проснулись, когда все, кому нужна кроссплатформенность, успели разбрестись по другим платформам.
DOU DevOps meetup19 вересня (Київ)
Zakhar Sukhanov
anonymous
Олексій Пєніє
Юрій Чугаєнко
Vladyslav Volkov
Vladyslav Melnyk
Andriy Goncharyk
Valentyn Ponomarenko
Dmytro Sirenko
Andrey Anastassiev
Valentin Nechayev
Andrey Anastassiev
Mobile
Lyova Zi
Євген Лесько
De Money
Андрій Козачук
Yuriy Pitometsu
undefined pointer
Євген Лесько
Igor Melnick
undefined pointer
Максим Ситников
Sergii Vashchyshchuk
Vladimir Pauchev
Konstantin Strukov
Arthur Kushka
Олександр Мацько
Vladyslav Kurmaz
Anastasiia Nevidomska
Alex Dev
Oleksii Shevchuk
Andriy Krot
Dmytro Zharii
minodvesP Vasya
Yury Gavrilenko
Sergei Epatov
Stanislav Mykhailenko
Sergey Knyazev
Serge Ribalchenko
Sergiy Morenets
Eugene Dobrovolskyi
Andrii Serhiienko
Дмитро Дем'яненко
oleksandr dubyna
oleksandr dubyna
Jorzchyk Pushysty
Андрей
Евгений Сосна
Fedir Tsapana
Нестор Иванович
Anton Fimin
Mykola Gurov
Владимир Жаворонков
Олексій Пєніє
Ievgen
Andrusenko Dmytro
sanchez
IRD
Dunkan M
Eugene Kyba
Фуад Леонардович
Sergio Gonzales
stone: switch(direction) {
case LEFT:
horse = null;
break;
case RIGHT:
head--;
break;
case STRAIGHT:
horse = null;
head--;
break;
default:
horse.addEvent(Death.getNewInstance(Horse.class, Death.STARVE));
DeathCause epicCause = Death.Uncanny.createByProphet("от коня своего");
Олег.addEvent(Death.getNewInstance(Human.class, epicCause));
Олег.addEvent(DarvinAward.newInstance());
Пушкин.CreativeFactory.write("Песнь о вещем Олеге");
}
Если есть лет 10 на разработку того, что на той же Java можно написать за месяц. Но будет летать — однозначно
И какой дурак будет писать на ассемблере то, что возможно разработать на Java?
Ihor Bodnar
Найкращі коментарі пропустити