×Закрыть

Чем старее технология — тем больше она продержится

Часто при выборе библиотек я сталкиваюсь с тем что разработчики предпочитают самые новые технологии, а начальство — технологии за которыми стоят «большие имена» / при равной распространенности и приминимости.

Я же немного старомоден и не уверен что выбор
самой старой из подходящих технологий не оправдан.

Недавно я натолкнулся на однодумца www.johndcook.com/...2/12/17/the-lindy-effect :

The longer a technology has been around, the longer it’s likely to stay around.

Подобная идея оказывается не нова, например есть запись на вики en.wikipedia.org/wiki/Lindy_Effect

В свободное время я сделал программу которая выдает статистику по используемым библиотекам в рамках maven проекта (выдает csv файл с возрастом используемых библиотек): github.com/bogdartysh/lindy-stat

Следующим шагом планирую проверить предположение на доступных opensource проектах

Если кому интересно, присоединяйтесь.

PS: под «дольше всего продерижтся» имеется в виду «достигнет end-of-life»

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Да, это прикольно. Вот еще про Lindy effect в приложении к стартапам: blog.asmartbear.com/lindy-effect.html

кстати, мне тут пришло в голову что по сути Java Garbage collector работает исходя из того же принципа — объекты которые пережили n проверок в дальнейшем проверяются на порядок реже. bogdanartyushenko.blogspot.com/...va-garbage-collector.html

Полностью не согласен.
За своими библиотеками нужно следить и обновлять их постоянно, так как:
1. Люди выпускают новые версии — фиксят баги.
2. Добавляют фичи.

Если этого не делать, то проект превращается в кусок «овна» мамонта, который:
1. Очень сложно поддерживать.
2. Сложно и дорого/долго добавлять новые фичи.
3. При необходимости обновить библиотеки проекта, Вы будете кушать успакоительное пачками и надеяться, чтобы после обновления оно все не упало на продакшене.

Девелопер должен решать задачи быстро, эффективно и без попоболи :), а не копаться в legacy коде.

За своими библиотеками нужно следить и обновлять их постоянно, так как:
1. Люди выпускают новые версии — фиксят баги.
2. Добавляют фичи.

ви оце щойно винайшли composer / gem bundler / ...

Девелопер должен решать задачи быстро, эффективно и без попоболи :), а не копаться в legacy коде.
Ага, а подчищать косяки за этим девелопером через N лет будут марсиане...

blogs.wsj.com/...-is-dead-long-live-cobol — ярчайший пример. Существует дохрена всякого enterprise/military/governement legacy которое надо поддерживать/допиливать. И не только COBOL. + еще всякие SAP, Siebel и прочие иже с ними.
И там даже и денег можно поболее срубить. Но это боль. Даже интегрироваться с подобными системами это муки и страдания, а уж что то в них делать... Ух. Впрочем, в рамках украинского IT это не актуально. Никогда такая разработка в офшоры не пойдет.

Как для Вас расшифровывается «больше продержится»?
Если речь о надежности — то какая-то логика в этом есть: в старой технологии уже наверняка выловили и починили больше багов. Поэтому если ее использовать в тех же условиях (на старом железе) — то можно ожидать высокой надежности. В качестве примера можно привести совковые технологии, которые до сих пор применяются на космических кораблях, для управления атомными станциями, в военной технике. Это как раз тот случай, когда надежное старое безопаснее, чем плохо проверенное новое.
Понятно, что если пытаться применить старую технологию на новом железе — то надежность будет хуже, чем от новой, под него разработанной.
Если же «больше продержится» — это значит результат будет дольше востребован, то тут не соглашусь. Современные ИТ продукты чаше «умирают» не от того, что «испортились», а от того, что устарели. И выбор старой технологии, которая не сможет работать в новых условиях без «костылей» — нелогичный шаг.
То же если «больше продержится» — значит «принесет больше профита». Очевидно, что собрать новую систему, которая должна решать современные задачи, на современных технологиях, которые придумали именно для решения этих новых задач, будет быстрее, чем применить старую технологию, которая разрабатывалась до того, как новые задачи возникли. И сейчас быстрее получить даже «сырой» результат и начать получать прибыль выгоднее, чем долго разрабатывать на проверенной надежной технологии.
Это выгоднее даже в долгосрочной перспективе: иметь недорогую (пускай и не очень надежную) систему, быстро собранную на современных технологиях. Потому что через несколько лет, когда ситуация на рынке поменяется, она уже себя окупила. И можно собирать новую, которая отвечает современным вызовам. А вложив деньги в дорогое и надежное решение получим «мертвую лошадь», которую тяжело приспособить к новому, но и выкинуть жалко.

Как для Вас расшифровывается «больше продержится»?
изначально я понимал «достигнет end-of-life» (en.wikipedia.org/...ftware_release_life_cycle)

на счет железа несколько не согласен. Скореее можно говорить о том что новое железо не всегда увеличит производительность старого, не оптимизированного софта. О том, что он прямо сломаеться — не хфакт.

это бред. работаю веб и мобайл разработчиком 4+ лет. В большинстве случаев переписать старье стоит дешевле и быстрее и потом дешевле в поддержке, чем тащить индуский код. А с учетом развития технологий часто несколько тысяч строк можно заменить парой десятков (например заююзать энтайти вместо прямого общения с БД в си шарпе) и много других плюшек. Та же аутентификация и авторизация уже есть написанаая в новых Фреймворках, и юзать ее логично и правильно, а не писать/дописывать к старью... уже реализованый проф функционал и тд. Ну и производительность с новыми технологиями растет, если с мозгами их юзать..... одни плюсы в общем и только минусы в использовании старья.... за исключением определ случаев.... которые увы есть и там не поспоришь. а везде в остальном — прогресс!

Это потому что в мобайл старого кода считай что нету.

Ну и производительность с новыми технологиями растет, если с мозгами их юзать.....
Не факт, новые фреймворки экономят время девелопера за счет более высокого уровня абстракции. Но за это нужно платить :(

я не видел ни одного теста новых версий Фреймворков, где они б были медленней предыдущих. так то производительность растет.

писал и на том и на том. смотря как писать.

Дельфисты плюсуют этот пост

Программисты на COBOL и RPG тоже одобряют.

этих уже только вперед ногами с рынка вынесут
причем новое поколение в Индии неустанно готовят на замену- все майнфремщики моложе 50ти что я знаю как раз с тех краев

Ох блин... Я уже почти три года переписываю с делфи на С++/C#

А смысл? Изначальная посылка поста ошибочная, оглянитесь вокруг.

Чем старее технология — тем больше она продержится
Слова — такая штука которая имеет значение и окрас. «Старее», «старше», «зрелее» чем-то похожи, но при этом окрас (та и значение) у ни довольно разные.
The longer a technology has been around, the longer it’s likely to stay around.
Мне почему-то хочется перевести эту фразу:
Чем дольше технология в использовании, тем дольше она будет в использовании.
И это можно легко объяснить, в отличии от «Чем старее технология — тем больше она продержится». Банально вспомнить Struts, это один из самых старых MVC фреймворков для Java, но при этом он совсем не «держится».
.
P.S. «apache stripes» — а когда Stripes стал апачевским проектом?
P.S. «apache stripes» — а когда Stripes стал апачевским проектом?
— насколько знаю apache struts, stripes — сам по себе (хотя использует лицензию апача)

Подписаться на комментарии