Как стать автором
Обновить

Комментарии 239

Концепция чёрной дыры появилась не в XX, даже не в XIX, а ещё в XVIII веке. Можно ли из-за этого говорить, что с тех пор физика чёрных дыр не развивается?
Между перцептроном и современными архитектурами настоящая пропасть. И пропасть идейная, а не просто картинок в интернете больше стало.
Языки тоже развиваются, становятся проще для использования, но это отдельная большая тема.
Я понимаю, о чём Вы говорите — прорывов нет, однако есть устойчивое развитие технологии. Это путь не революции, а эволюции. Изменений вроде бы мало, они незначительны, однако сравните ассемблер и Python, например. Или AlphaGo и любой игровой движок до этого.
Между перцептроном и современными архитектурами настоящая пропасть. И пропасть идейная, а не просто картинок в интернете больше стало.

а можно подробнее?
может быть критерии выбора базовой функции новые появились? нет


какая новая идея пришла в этот мир? и важно чтоб в последние 25 лет?


Я понимаю, о чём Вы говорите — прорывов нет, однако есть устойчивое развитие технологии.

экстенсивное развитие.


Есть новые парадигмы программирования, сравнимые со скажем ООП?


Изменений вроде бы мало, они незначительны, однако сравните ассемблер и Python, например.

однако 25 лет назад был Perl, Java. Что нового привнёс Python? какие новые технологии?
Почему Python Вы сравниваете с ассемблером, который был распространён гораздо больше чем пол века назад?
И самому Python уже сколько лет? Есть ли языки с новыми парадигмами, а не просто дающие чуть другой синтаксис?

Это вы о прорывах говорите. А в статье у вас про «развития в программировании нет». Это разные вещи.

статья не отрицает экстенсивное развитие.

Заголовок отрицает

экстенсивное развитие - это увеличение количества, а не качества

да иногда, по известному закону, количество дает новое качество, но по большому счету экстенсивное развитие это не развитие, а банальное заполнение пустого пространства

Что такое базовая функция?
Навскидку из новых идей: BERT, word2vec, LSTM, много новых свёрточных архитектур.
Парадигм новых нет, это правда. Однако если рассуждать такими крупными мазками, то в биологии тоже после Дарвина ничего не было. Это так? Вы, кстати, не ответили на вопрос про чёрные дыры.
«Чуть другой синтаксис» — это ускорение разработки, наверное, на порядок. И это интенсивное развитие. Сравните Java 25 лет назад и сейчас, это почти разные языки. Вы невольно подразумеваете, что язык вышел и замер в своём развитии, но это не так. Повторюсь, есть эволюция.
P.S. я Вам плюс на комментарий поставил, не думайте, что минусую за мнение, отличное от моего
Чуть другой синтаксис» — это ускорение разработки, наверное, на порядок.

нет.


парадигма Go отлично ложится на C++. Докажите, что на Go разрабатывать на порядок быстрее чем на C++.


Сравните Java 25 лет назад и сейчас, это почти разные языки.

в чём разница? появление нескольких синтаксических конструкций и рефакторинг движка, исполняющего байткод под манипуляции большими объемами данных?


это чистый экстенсив

Вы последовательно не отвечаете на мои вопросы-аналогии, поэтому это моя последняя реплика.
Зачем мне доказывать разницу между C++ и go, если я изначально про ассемблер говорил?
«Несколько синтаксических конструкций» я называю эволюцией, и это и есть развитие.
Отрасль развивается и экстенсивно (новые языки программирования, например), и интенсивно — удачные языки программирования завоёвывают нишу и развиваются, чтобы их не смели. Эволюция видов в чистом виде.
Дарвин о генах еще ничего не знал.

Я пытался с позиции автора статьи рассмотреть естественные науки. Если продолжать так рассуждать, то гены - это всего лишь техника, не более.

Если же говорить от своего имени, то и программирование, и биология, и физика развиваются

… и Менделеев об электронах.
Последние четверть века развития в программировании нет
Является ли это прорывом? Нет. Новой технологией? Нет.
какие новые технологии?

Когда это вдруг "развитие" стало означать исключительно прорыв и новые технологии?

Между перцептроном и современными архитектурами настоящая пропасть. И пропасть идейная, а не просто картинок в интернете больше стало.

Пропасть вряд ли. Я изучал нейросети в середине 1990-х, уже тогда это была зрелая дисциплина, существующая не одно десятилетие. Единственное, что кардинально изменилось с тех пор — тысячеядерные процессоры, на которых их можно эффективно запускать, стали карманного размера и доступной стоимости. Поэтому технология, интересная ранее только кругу учёных с мейнфреймами за стенкой, пошла в массы.
Я выше перечислил архитектуры, которые вышли недавно. Хорошо, пропасть — это экспрессивная характеристика, однако развитие очень сильное.

Я прям даже удивлён такому количеству плюсов. Нейросети зрелая дисциплина в 1990-х? Возможно. Между результатами тогда и сейчас пропасть — определённо. Любой, кто будет утверждать обратное просто не понимает или вовсе не знает какие результаты были возможны с нейросетями тогда и какие сейчас.


Да, тысячеядерные процессоры (наравне с терабайтами данных и быстрыми сетями и миллионами новых исследователей) послужили фактором, позволившим совершить этот скачёк, но одновременно с ростом понимания, пришли и возможности оптимизации и современные подходы позволяют запихивать весьма серьезную функциональность даже в микроконтроллеры, похожие по мощности на то, что было процессорами в середине девяностых. Функциональность совершенно недоступную тогдашним нейронкам. И нет, не было особо никаких "учёных с мейнфреймами за стенкой" или назовите парочку работ от таких учёных, посмотрим чего там на мейнфреймах делали.

И все же это развитие количественное, а не качественное. Ну, как развитие графония между первым халфлайфом и каким-нибудь крузисом-баттолфилдом. Да, появились новые финты, вроде batch normalization или конкретного метода dropout, но фундамент под всем этим нам читали на кафедре в 2010-м (и, уверен, читали DrPass 'у в девяностых).


У условной QTT, лежащей в основе второго идриса, имхо, новизны больше.

Что ж, могу на это только сказать что не фундамент задачи решает. Возьмите фундамент и оправьте его хотя бы котёнка от собаки отличить.

Возьмите фундамент и оправьте его хотя бы котёнка от собаки отличить.

Делал году в 2011-м в рамках домашнего задания к семинару в вузе (даже не уровень курсача), без всякого глубокого обучения, а что?


Что ж, могу на это только сказать что не фундамент задачи решает.

Безусловно. Количественное развитие тоже важно. И, если позволите пропустить несколько шагов рассуждений, сразу скажу — смысла в исходной статье (вернее, в поднятом там вопросе) я не вижу. Как разница, есть новые фундаментальные идеи или нет? Что делать-то?

без всякого глубокого обучения, а что?

Просто было интересно, что у вас в "фундамент" войдёт :)


Количественное развитие тоже важно.

Позволю себе лишь не согласиться с определением развития как "количественного". Развивается количество чего? Непонятно. А вот то, что у систем появляются новые свойства, решаются задачи, которые ранее не решались — это вполне себе развитие. Даже если взять пример графония — раньше решалась задача "показать что-то похожее на реальный мир", а сейчас решается задача "показать такой мир, какой хочется показать, будь это неотличимо от реальности или картинно-мультяшно". Так и с нейросетями — в начале девяностых было "О, у нас нейронка индекс на пакете читает!", а стало "нейронка делает всё, от вождения авто, через распознавание котиков (и вообще миллиарда объектов), голоса (в текст и наоборот), кувыркающихся роботов, генерации фотореалистичных картинок до физических симуляций и той же 3д-графики и пишет тексты на заданную тему, включая код на уровне джуна".


Как разница, есть новые фундаментальные идеи или нет? Что делать-то?

Вообще не вижу проблем, задачи решаются, все при деле, только автор лепит соломенных человечков и борется с ними активно. Кто-то на самом деле говорил, что из области выпадаешь за полгода? Лол же, в таком случае в область никто и попасть бы не смог (ведь это тождественно выпадению из области на бесконечность, а это > полгода), а раз могут, значит и опытный разработчик не выпадет. Но и тезис о том, что учиться не надо тоже фигня — даже если джун после универа знает все-привсе нужные "парадигмы", всё равно существует куча process knowledge и domain knowledge, и тот, кто будет больше этого знать и уметь, получит преимущество в отрасли.

Глядя на то куда катится этот мир представить что будет дальше ))
Думаю уже скоро процессоры очень сильно обрастут специализированными ядрами (apple уже задал трэнд)
Через какое то время понятие жесткий диск исчезнет как класс.
Каналы связи будут обеспечивать возможность прокачивать 8k или больше по воздуху.
Допилят устройства виртуальной реальности (без лупы в маленький экран), думаю индустрия порно закачает денег на это направление.
Страничка в браузере, в очках виртуальной реальности с прогнозом погоды (который конечно же не точен как и сейчас) будет так же тормозить, несмотря на 300 ядер с десятком терабайт на борту (девайс переносной, потому слабенький, батарейка иначе тяжелая)
Телевизионные передачи и фильмы сольются с рекламой в единое целое донося до наших мозгов правильные трэнды.
Спутниковая связь подешевеет в пару раз, или наоборот подорожает раз 5 (хотя куда уж дороже то)
Алиса наконец сможет поддерживать разговор с 3 летним ребенком, но он к тому моменту станет здоровым детиной, одна надежда на внуков.
Выйдет 3 или 4 ремейк вашего любимого фильма, в новом супер разрешении с ощущением приближенным к реальности (тут возможно и наркотики соответствующие добавятся, но не везде)
Человек высадится на Луне в прямом эфире.

Оптимистично как то получилось. )
Но лучше так чем опять дубины и шкуры ))
да, это уж слишком оптимистично. Помнится, стремились развивать индустрию музыки, да в супер качестве. Кассета — CD — mp3 — DVD-Audio… а тут уже предел идеала. А идеалистов мало, и они нищие. Какое развитие? Продажа mp3 по подписке!
Поэтому не удивлюсь, что вместо каналов 8к каждому клиенту, опять изобретут карты доступа в интернет с погигабайтной/минутной тарификацией… погодите-ка.., а сим-карта! И закон Мура про процессоры когда там забуксовал?
И закон Мура про процессоры когда там забуксовал?

а уже забуксовал? вроде частота остановилась, но она компенсируется числом ядер.

Автор статьи сделал правильное сравнение отрасли с «беличьим колесом». Цифровые технологии ускоряют процессы существовавшие ранее и без них. Если раньше «колесо» крутилось медленно, то сегодня оно крутится быстрее, но оно по прежнему колесо.

Область применения программного обеспечения остаётся прежней: Автоматизация, в том числе бизнес процессов. «Ключевая концепция нынешнего десятилетия — скорость» [Б.Гейтс]

Скажите, когда концепция типажей появилась? По моим ощущениям, это один из крупных прорывов в системе типов, который одновременно сохраняет строгость статической типизации и даёт все бонусы утиной типизации, одновременно.


На более низком уровне — immutable infrastructure и iaac. Оба — весьма тектонические изменения в работе ПО.

это Rust? В C++/Java давно есть интерфейсы.

Интерфейсы, насколько я знаю, не приводят к type erasure (поправьте меня, если приводят). Т.е. в зависимости от того, это мономорфизация или динамическая диспатчеризация, от исходного типа остаётся только подмножество методов, соответствующих заявленному трейту. Более того, между трейтами не существует никакой специальной иерархии, т.е. всякие diamond inheritance отсутствуют как класс. Есть просто список методов, соответствующих перечислению необходимых трейтов (например, Ord + Display позволяет сортировать и показывать, но ничего кроме этого).

Disclaimer: цифры условные, прошу не придираться с калькулятором в руке :)
Я, возможно, просто старый скептик, но вот мой опыт никак не позволяет называть это прорывами. Это мелкий синтаксический сахар, никакого влияния на разработку не оказывающий в 99.999% случаев. Потому что 99.9% программистов его либо не используют, либо используют не по назначению, а из оставшихся 0.1% подавляющее большинство не страдало от ошибок с типизацией и без него.

Ну, давайте, тогда, рубить правду-матку до самого дна. Всё прорывное было сделано Гёделем, Расселом и Тьюрингом. Все последующие открытия — мелкий синтаксический сахар на фоне грандиозности Тьюринг-машины и Гёделевых ординалов.

в общем-то примерно так оно и есть

представим, что человечество научилось копать канавы (до этого не умело) и проводить воду в те места где её не было. копание - новая технология

но затем копание применяется повсюду, увеличение рабочих с лопатами и даже их более высокая зарплата - это не развитие, а экстенсивное заполнение пространства.

Рабочий-землекоп, временно проработавший кассиром лет 15-20, ничего не теряет в квалификации, несмотря на то, что форма лопат и канав со временем меняются. Несмотря так же на то, что способы управления землекопами тоже меняются со временем...

Только вот, чтобы ваша аналогия была больше похожа на реальность разработки софта (и более широко программно-аппаратных систем), то теория того, что землю можно копать была разработана ещё в древние времена и тогда же научились копать лопатами. Но вот незадача, в современном мире под копанием понимают все возможные земляные работы — и "копание" тоннелей для метро, и тоннели под океаном и шахты и бурение кольской сверхглубокой и угольные карьеры и "канавы" под укладку кабеля на дне океана.

Абсолютно правильная аналогия. Вот делал землекоп канавы для орошения — и продолжает делать. Например, что сложного в сливе для гигаваттной ГЭС? Та же канава, только побольше.

Все последующие открытия — мелкий синтаксический сахар на фоне грандиозности Тьюринг-машины и Гёделевых ординалов.

Я не это имею в виду. Изменения, кардинально меняющие производительность программистов, они другие. Например, async/await, пусть и основаны на неких старых принципах, они меняют кардинально, потому что помогают решить проблему отзывчивости приложений, с которой реально рано или поздно сталкиваются практически все, и решение которой бывало либо мучительно больным, либо мучительно сложным. Очень много изменений, влияющих на продуктивность программиста, происходило в IDE. Даже больше, чем в языках. Касаемо отладки, касаемо профилирования, касаемо визуальной разработки. Очень много изменений — в библиотеках/фреймворках, будь-то биндинги, реактивность и т.д. Но тут есть одна неприятная фишка, значительная часть актуальных инноваций в современном мире JS — это уже повторение пройденного пути в мире десктопных приложений в 1990-е годы. И вот поэтому я тоже считаю, что развитие современной разработки забуксовало. Нет того революционного роста продуктивности разработчика, который был раньше.

async/await не решает проблему отзывчивости. Он позволяет снизить накладные расходы на многопоточности (за счёт малой толщины языко-ассистированного стека).


В целом, с точки зрения продуктивности, изменилась инфраструктура.


О, вот, как вам "зависимости из интернетов"? requirements.txt — это уже 21ый век. Так же как и концепция .lock'а для зависимостей.


В целом, git — это большая революция. Кто пользовался svn подтвердит.


Концепция MR/PR вышла в абсолютный мейнстрим.


Фреймворки тестирования достигли невероятных высот по сравнению (с условным 2000ым).


Алсо, современную JS-среду (npm-мир) я считаю болотом в котором неконсистеность и шапкозакидательство — норма.

async/await не решает проблему отзывчивости. Он позволяет снизить накладные расходы на многопоточности

Я с вами не соглашусь. Во-первых, async/await — это лишь частный случай использования многопоточности. Во-вторых, сама по себе многопоточность — это не самоцель. Это инструмент, решающий в основном две проблемы: отзывчивости приложений и более полной утилизации ресурсов компьютера. Async/await большей частью используется именно для решения первой проблемы, на вторую больше нацелены библиотеки параллельных вычислений.
В целом, с точки зрения продуктивности, изменилась инфраструктура

Я про это и писал. Но основной мой посыл был в том, что инфраструктура/инструментарий, условно говоря, улучшились на два порядка в период с 1980 по 2000, и на 20% в период с 2000 по 2020-й. Да, git лучше svn. А svn был лучше vss. Стали ли мы многократно продуктивнее, перейдя от vss к git? Лично я не могу такого сказать. Может быть, мой опыт и ошибочный в какой-то мере, но я помню качественный скачок в продуктивности, когда мы внедрили vss в 1997-м, но я в упор не помню качественного скачка, когда мы внедрили git вместо svn в 2008-м. Подавляющее большинство изменений были «под капотом» и на реальную нашу работу влияния не оказывали. Да, в гите были локальные репы, в svn всё сливалось в центральный, но где-то в том древнем мире, в котором не было локальных реп, разработчики просто работали в своих бранчах, а какие-то текущие правки вообще не коммитили, пока они не доводились до удобоваримого состояния, и это работало ничуть не хуже :)
Концепция MR/PR вышла в абсолютный мейнстрим.

Я не знаю этой аббревиатуры. Каюсь :( Расскажите, плз.
Фреймворки тестирования достигли невероятных высот по сравнению (с условным 2000ым).

В условном 2000-м концепция TDD только недавно была сформулирована, хотя критичные к этому продукты уже давно писались с тестовыми скриптами, да и софта для UI-тестирования было навалом, ибо виндовый UI это позволял достаточно легко делать. Да, сейчас подходы более систематизировались, плюс, тестовые фреймворки вовсю используют возможности IoC, что само по себе не особо было распространено в 2000-м, но тем не менее, тестировать и тогда умели, только делали это иначе.
Алсо, современную JS-среду (npm-мир) я считаю болотом

Я тоже. Но вот только это — самый-самый мейнстрим современной разработки, а не какая-то там несчастная побочная ветвь.

MR — merge request, PR — pull request. Концепция ревью кода. Она была в каком-то виде в LKML в мейллисте, но в вот современный вид (с множественными фиксами по мотивам ревью), не как "высшие достижения", а как нормальный рабочий процесс — я видел процесс его становления в 10ые годы.


Я в инфраструктуре работаю, и я недавно как раз заметил, что у меня бутстрап проекта (не сервера, а проекта!) занял около часа. На выходе там было всё — пользователи, мониторинг с эскалациями, кастомные репозитории, инфраструктура для инфра тестов (включая ephimerial-машины), тесты мониторинга и т.д. В 2000ом у меня подъём такой инфраструктуры занял бы больше месяца, и оно было бы худшего качества.


А JS — маленький мирок. Тем, кто там крутится, кажется, что весь мир состоит из JS. Тем, кто вне его, JS — где-то сбоку "на вебсайтах и в электроне".

async/await не решает проблему отзывчивости

Ну почему. Изначально async/await микрософт придумали для выноса вычислений с главного потока именно в целях повышения отзывчивости. Он вообще не про многопоточность, т.к. в основном это все запускается в одном потоке и ворочается стейтмашиной, а весь смысл в использовании асинхронного IO. Возможность что-то отправить в соседний поток и ждать выполнения это уже скорее более сложный нестандартный случай. Ну, по крайней мере, если судить по опыту с шарпом.
микрософт придумали

кажется это до них было?


или они именно эту кошмарную связку async/await именно выдали?

Я уж не знаю что там в научных кругах, но на моей памяти именно микрософт с сишарпом начали весь современный тренд async/await. Вики говорит, что пришло оно из F#. Собственно, как обычно. У МС это песочница для обкатки новых фич сишарпа.

Тайпклассы — это совсем не просто сахар.


Не, можно считать их частным случаем auto implicit-аргументов в стиле идриса или агды (и это довольно хорошее обобщение), но так редко делают.

В Haskell есть типы и классы (декларативный), в C++ классы и интерфейсы (императивный). Это все похоже на синтаксический сахар с акцентом на определенной абстрактной идее. Похоже я сильно отстал от IT или просто термины используются другие.
Зы сейчас IT идет в сторону бесшовного перехода между декларативным стилем и императивным, создавая потребность в новом словаре для информатики.

Хаскелевские классы совсем отличаются от плюсовых.

Ну да, я зря их рядом в тексте поставил) Но вот что такое типажи? По синтаксису (если это к rust ) похоже на интерфейсы из Java, а еще немного на классы Haskell.

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

Я, в свою очередь, мимо раста проходил и не очень его знаю, но тамошние типажи как раз на хаскелевские тайпклассы очень похожи.

Ну так и как? Это крупнейший прорыв?

Я начинаю уставать от количества названий одного и того же. Это специально сделано? Похоже сегодня в IT нужно просто словарь пополнять, а не "гнаться за индустрией"...

Это не крупнейший прорыв, это одна из небольших фичей. А целиком набор таких фичей и заодно с этим вся философия и ценности языка (и его сообщества), которые направлены на достижение определённых целей (безопасность + скорость) — вполне себе прорыв, если под прорывом понимать появление инструмента, который позволяет хорошо решать конкретный класс задач с известными гарантиями.

Скажите, while — это синтаксический сахар для if/goto? Перменная — это синтаксический сахар для регистра и/или данных в памяти по указанному адресу?

while/if/goto/for/while-do, переменная, указатель, указатель на указатель, структура и тп. это все синтаксический сахар над 2-3 слоями абстракций. Но когда этих абстракций друг над другом доходит до десятка без серьезного прикладного значения, то начинает попахивать идиотизмом (чвс создателя подпитывает).

Зы против rust ничего не имею против

просто — способы размазывания большого объёма кода по нескольким файлам.


то есть если раньше это приходилось делать вводя лишние уровни наследования, то сейчас можно выделять в типажи.


новой концепции программирования тут примерно столько же сколько в директиве include.

На старых технологиях проекты в миллионы строк кода принципиально невозможно ни написать, ни поддерживать. Автомобили и 100 лет назад ездили, но были похуже лошадей даже.


Говорить, что масштабирование и развитие технологий, которое требует гораздо больше усилий, чем их создание — что-то не принципиально новое — бред. Сейчас любой хороший студент напишет программы, которые были 50 лет назад.
P.S. кстати не понял почему в статье 25 лет назад, когда 50 лет назад уже было все известно и понятно к чему идет.

Написать такое же приложение, как и 50 лет назад не проблема. Проблема не выйти за рамки 50ти летних системных требований.

Ядро linux, на 2017 год > 24 миллионов строк кода.
Там вроде c + asm в основном.
Если порыться среди открытых проектов объемы в миллион LOC не редкость, а еще есть банковское ПО на фортране и тд. Туда человеко-лет вложено уйма, и как то не горят переписывать, сильно дорого.

Проблема с "наследованием" состоит в том, что оно приносит полиси в реализацию там, где полиси не ожидают. Если у меня множественное наследование с конфликтующими методами, то разруливать это можно десятком разных методов, и все они уродливы.


В случае с трейтами "лишнее" просто отсутствует, а в случае неудачной коллизии по именам методов это видно в момент компиляции и требует всего лишь полного указания на метод (не 'foo', а Trait1::foo и Trait2::foo). Всё это в compile time с нулём неоднозначности.

Это, не совсем про программирование.

Infrastructure as code (IaC), шутка хоть и не древняя, но и не новая, по меркам автора статьи. Википедия отправляет нас в 2006 год.

Immutable Infrastructure - это действительно свежачёк. Известна точная дата появления термина 26 июня 2013 года Chad Fowler наиисал статью и твитнул о ней (вот этот твит)

В 1987 году первая реализация.
Type classes, which enable type-safe operator overloading, were first proposed by Philip Wadler and Stephen Blott for Standard ML but were first implemented in Haskell between 1987 and version 1.0

immutable infrastructure сильно позже, но явно уже больше 15 лет, загрузка по сети и модификацией шаблонов и образов снаружи использовалась вовсю.

iaas — тоже сильно давно, инструменты подтянулись и стали доступней, пошло в массовое использование, в 2005 — 2007 сетевики в провайдере где я работал использовали подход вовсю, у них была репа с конфигами, набор скриптов и тд
у админов уже был openvz, загрузка по сети, правка шаблонов автоматом и тд. основная часть инфры разворачивалась скриптами (ансибл эт тоже скрипты так то) и кстати проблемы с верификацией кода инфры тоже были (помнятся в основном ошибки при изменениях в dns и когда vlan-ы не туда прибивались) в общем все эти идеи сильно не новые.
Типажи — если мне не изменяет мой склероз, это конец восьмидесятых прошлого века. Один из диалектов Smalltalk, который, емнип, и появился практически исключительно для «проверки концепции».

Автомобилистроение самая слаборазвитая область из всех. Прошло 120 лет а автомобиля с квадратными колесами так и не появилось!

а вот автомобили как раз интенсивно развиваются: вобрали в себя IT (совершенно новые для них технологии).
ДВС вследствие этого догнали по КПД почти до теоретического максимума. итп


Статья об интенсивное vs экстенсивное развитие

Лучше бы не развивались в эту сторону. Придушенные по максимуму крошечные двигатели с крошечным ресурсом

Крошечные двигатели - а что в этом плохого? Если раньше требовался огромный, тяжёлый и прожорливый мотор, то сейчас ту же тягу выдаёт "кофемолка с турбиной", которая и легче, и экологичнее, и потребляет меньше топлива. Помните времена, когда 140 л/с было нормой для двухлитрового мотора? Не такие уж далёкие, кстати, времена. А сейчас ту же мощность выдаёт литровый EcoBoost.

Помните времена, когда 140 л/с было нормой для двухлитрового мотора? Не такие уж далёкие, кстати, времена. А сейчас ту же мощность выдаёт литровый EcoBoost.

Вот только покупать такой мотор не стоит. Он дохнет тысячах на 100-150 в среднем. Слишком напряженный и легкий.

Лучше классического двухлитрового атмосферника из конца 90тых примерно ничего не сделано. Он вечный почти.
Лучше классического двухлитрового атмосферника из конца 90тых примерно ничего не сделано. Он вечный почти.

Если заменить «лучше» на «надежнее», то вы будете правы. Но если «лучше» означает «дешевле», «экономичнее», «экологичнее» — то нет.
Вот именно КПД сейчас кладется в жертву экологичности.

Вот это странно, если не считать выбросов всяких редких элементов, то чем выше КПД, тем меньше расход топлива на одну и ту же дистанцию и значит экологичность выше.

В том и дело, что малым выбросам редкий кислот уделяется больше внимания, чем CO2. Поэтому дизелям конец уже сейчас, а бензиновым через несколько лет. В атмосфере планеты слишком много азота и добиться эффективного сжигания топлива в ДВС без образования NOx невозможно. Пора переходить на турбины внешнего сгорания и сжигать топливо в чистом кислороде.

Не развивается автомобилестроение совсем. Автор статьи не даст соврать.

Если честно, то со времен повозок ямной культуры никакого особого развития. Все те же четыре колеса. У некоторых больше, но это экстенсив. А так — подумаешь, заменили человека на вола, вола на лошадь, лошадь на ДВС — тоже сплошной экстенсив.

замена лошади на ДВС - качественный шаг

замена Perl на Python - это замена лошади на вола

Исторически меняли волов на лошадей, а не наоборот.

А замена лошади на ДВС — шаг исключительно экстенсивный. Было две лошадиных силы, стало сто две.

Проблема в том, что «экстенсивность» не имеет четкого определения, и поддается любой трактовке. Вы говорите, что перцептрон ничем принципиальным не отличается от современных сверточных сетей — я говорю, что четырехколесная повозка ямной культуры принципиально ничем не отличается от лендкрузера. Слово за слово.

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

Такое мнение тоже имеет право на жизнь.
Никто ничего не заменяет. Кому-то стало мало инструментов одного языка? Он создаёт другой. Кому-то ещё понравился этот новый язык? Он переходит на него. Вот и вся концепция, ничего сложного.
С таким отношением можно дойти хоть до машинного кода, с умным видом послав подальше любые улучшения.

Замена лошади на ДВС случилась 150 лет назад и с тех пор никакого развития. Ну подумаешь, стеклоподъёмники добавили, кресла мягкие, ремни безопасности, а так одно и то же — горящие углеводороды приводят в движение 4 колеса.

замена лошади на ДВС — качественный шаг

И лошадь, и ДВС работают на молекулах, которые при расщеплении дают энергию. Ничего нового.
"Развитие" это не синоним слова "прорыв", это синоним слова "улучшение".

"Развитие" это не синоним слова "прорыв", это синоним слова "улучшение".

экстенсивное развитие статья не отвергает, а напротив о нём говорит :)

Она говорит, что развития нет, это указано в заголовке, а оно есть.

Вы путаете понятия «развивается» и «кардинально новое». Попробуйте на ассемблере написать сопрограмму и на го, и вы почувствуете существенную разницу. Это развитие. Берем старое, комбинируем и развиваем.

Кардинально новое - это как появление машин и самолетов, но при этом в передвижении пешком ничего нового нет

> Попробуйте на ассемблере написать сопрограмму

А что в этом сложного? Идейно все довольно просто (и вообще википедия подсказывает, что все было придумано еще в 50-х), на любом макроассемблере можно повторить что-то вроде этой конструкции:

www.chiark.greenend.org.uk/~sgtatham/coroutines.html
Stackless корутины это самая примитивная реализация. Выше было про Go. Самая сложная часть рантайма там, помимо GC, это планировщик задач, сродни планировщику ОС — выделяет кванты времени, прерывает выполнение, переключает, балансирует, не дает никому голодать. Реализация этого займет много времени и годы уйдут на отладку на реальных нагрузках.
> планировщик задач, сродни планировщику ОС

Вообще-то несложный планировщик — это уже в 80-х упражнение для студентов профильной специальности на 2-3 курсе, а вовсе не rocket science.
Вообще-то речь не о примитивных планировщиках из пары очередей. Современный планировщик это очень сложная система. Как уже говорил, одно дело ее реализация, это уже не тривиально. Другое дело заставить ее работать на реальных нагрузках. Что линукс, что винда, что го — все они годами отлаживают свои планировщики и конца этому не видно.
Erlang? Планировщик, зеленые трэды и прочее.
developed by Joe Armstrong, Robert Virding, and Mike Williams in 1986,
Чего эрланг? Да, он внутри тоже примерно тоже самое делает. По-проще, но примерно похоже. Его шедулер, тем не менее, тоже не тривиальный, т.к. язык сразу закладывал большие цели и вроде как их добился. И думаю у них точно так же ушли многие годы на его отладку. Плюс, не думаю, что реализация 1986 года была какой-то продвинутой. Все же успех эрланга это его BEAM райнтайм, который появился сильно позже, а уж поддержку многопроцессорности так вообще в 2006 добавили, судя по всему.
Ну про то и речь, планировщик, не тривиальный, реализован в 1986 году. Успех пошел когда его код открытым стал вместе с ОТП
В 1986 году как бы и железо было сильно другое, и на том железе с теми ресурсами что были доступны физически, зеленые потоки и прочие плюшки…

The early OTP system components in 1998

Distributed application management
SASL — error logging, release handling
OS resource monitoring
EVA — protocol independent event/alarm handling
Mnesia — real-time active data replication
SNMP — operations and maintenance interface
INETS — simple HTTP support
A key subsystem in OTP is the System Architecture Support Libraries (SASL), which gave a framework for writing applications. The early version of SASL provided:[5]

Start-up scripts
An application concept
Behaviours (design patterns)
Error handling
Debugging
High-level software upgrade in runtime without shutdown
The behaviours provide programmers with yet higher abstractions for efficient program design. The early version included:[5]

Supervision
Servers
Event handling
Finite-state machines

Что нового добавил GO?
Я собственно не против языка как такового, но каких-то прорывных вещей в нем я не вижу. В общем то язык заточен под одну необходимость, простота ротации людей по проектам. Код всегда линеен и прост. Хотя тут всегда есть нюансы ))

Вы очень сильно переоцениваете сложность планировщика. Подходы известны и описаны (work stealing queue), кода, думаю, будет пара тысяч строк. Асинхронный лок- ещё 200-400 строк (посмотрите на semaphoreslim в .net), а больше вам уже и не надо.

На отладку этого уйдёт пара дней, после чего за пару лет счастливые юзеры найдут ещё пяток сложных багов.

В общем то, в приведенной вами ссылке наверняка ничего. Но в go программисту можно просто добавить 2 символа к вызову и он будет уверен, что код выполнится на каком-то другом свободном потоке и он с ним сможет легко общаться. Все можно сделать «руками» и отлаживать всю жизнь до смерти проекта, но благодаря развитию у нас уже много готового и отлаженного «из коробки»

То что сейчас прорывное и революционное может быть просто мало известно даже специализированной публике. Приведу пример из своей области — методы таргетной терапии опухолей, которые во все возрастающем количестве случаев позволяют вылечить злокачественные опухоли, неизлечимые другими методами, базируются на наработках и технологиях 80-хх и часто 70-хх годов прошлого века. До клиники они шли 30 лет и более. Современные методы лечения таких заболеваний как расеяный склероз, язвенный колити многие другие разрабатывались многими поколениями. Другой пример, не из моей области — концепции электромобилей больше века, литий-йонным батаерям почти 40 лет. Маск даже не первый кто впихнул в корпус автомобиля батарейки для ноутбука, но первый кто сделал эту технологию мейнстримовой. Третий пример, который может проявиться — технологии термоядерного синтеза 80 лет, как и разговорам о его применении для выроботки энергии. Но почти все эти годы этим занимались ученые, с целями совсем иными. Лишь недавно, в связи с созреванием других не так чтобы очень молодых технологий (высокотемпературные сверхпроводники из 80-хх, методы модолеривания плазмы оттуда же) стало появляться множество стартапов, некоторые с прекрасным оснащением и хорошими щансам на реализацию.
Велиие вещи обычно начинаются просто и тихо. С шума начинается лишь большой обман.

Тут ещё можно вспомнить OLED, которые впервые появились 70 лет назад, но широкое коммерческое производство началось только 10 лет назад.

Когда говорите, что учиться надо постоянно не только в программировании, но и в бухгалтерии вы путаете теплое с мягким. Программирование — инженерия, даже гораздо больше, чем любая другая. Программирование не существует отдельно от прикладной сферы, оно встречается и на заводах и в телефонах и в автомобилестроении и в обучении и в бухгалтерии, каждая предметная область имеет свои нюансы и имеет свой Аппаратно Программный Комплекс.


Прыгая с проекта музыкальной библиотеки на мобильные карты, неплохо подучить координатные системы и простейшие формулы геодезии, плюс еще технологии, которые разработаны в этой сфере. Понятно, если вы сидите в 1С и все время настраиваете бухгалтерию, то скорость вашего условного обучения равна скорости обучения бухгалтера.

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

Понятно, что статья немного троллинговая. Тем не менее, с точки зрения юзабилити:

Сферическая в вакууме программа для скажем win95 запускалась и работала на порядок быстрее, чем обычная программа сейчас

Сферическая программа какая именно? ;) winrar подойдёт?

Ресурсы по запросу — огромный скачок в технологиях, на мой взгляд. Назовем это облаком, виртуализацией, контейнеризацией или как-то еще, но возможность получить необходимые ресурсы на требуемое время решает кучу проблем. Скажем, если мне нужно скачать датасет на несколько терабайт и обработать его в оперативной памяти, я беру облачную виртуалку для запуска скрипта на питоне, за час пишу скрипт с помощью numpy+scipy+xarray+dask и получаю и скачиваю результат, заплатив за все про все около 30$. На ноутбуке приходится неделю писать аналогичную программу на C и еще неделю ждать результатов. 20 лет назад у меня на диплом (голография в нелинейных оптических средах) вычисления запускались в течении пары лет на домашнем компе и нескольких компьютерах на кафедре, а сегодня это можно вычислить в облаке за неделю и в разы дешевле, чем было потрачено на покупку компьютеров тогда (все оплачивалось из наших же спецстипендий, включая технику на кафедре).

Это скачок не в технологиях, а в стоимости железа. В экономике то есть.
Go — пожалуй, самый отличающийся от других из новых языков.
Так ведь Rust самый отличающийся, разве нет?

И ничего не сказано про виртуализацию на процах. Раньше не было всяких VT-x и т.п., и была просто эмуляция.

На IBM была полноценная виртуализация в 80е

все эти docker'ы - это же просто развитие chroot, добавили к chroot лимитов и съединообразили способ генерации.

это то же, как, например труд курьера автоматизировать...

Нет, от chroot до современного докера был проделан огромный путь. Докер это не просто chroot, это файловая система на слоях, виртуализация сети, лимиты (cgroups это не простая система), формат контейнеров, формат описания их сборки и наверное еще куча вещей. chroot это маленький кирпичик в этом всем.

Гораздо раньше. VM/370 вышла в 1972, и она не первая.

В 70-е. Мало того, уже тогда полноценно работала nested virualization. То-есть запустить, допустим, новую версию гипервизора, на имеющеся, а в нём соответственно гостевую ОС, для того что-б протестировать новый функционал и совместимость с имеющимся софтом, было вполне штатным явлением.

Rust

какие новые парадигмы программирования предлагает Rust?

строгая типизация доступна и в С++ времени Страуструпа

А при чём тут парадигмы? :)
Но если так хотите, то например автоматическое освобождение памяти при выходе переменных из зоны видимости. Или такое уже было?
А принципы владения и времени жизни вообще не новые принципы?

было, принципы не новые

Cyclone это уже конец 90ых. Не 50 лет назад.

LISP — это по моему уже лет 70. Там было и освобождение памяти и принципы владения и так далее.


Вообще большинство "современных технологий" (вроде map/reduce) они к нам именно из Лиспа пришли

автоматическое освобождение памяти при выходе переменных из зоны видимости

RAII
А принципы владения

auto_ptr, unique_ptr
Но тут нужно уточнение, что Rust проверят это во время компиляции и это шикарно.

времени жизни

{
int a = 0;
}
a = 1; //error

???

Вопрос про use after free.
В C можно вот так:

int *a;
{
    int b = 0
    a = &b
}
*a = 1 //use after free

А раст такое не позволяет - ссылка не может жить дольше объекта, на который указывает.

А принципы владения и времени жизни вообще не новые принципы?

Теория — Жирар, линейная логика, семидесятые-восьмидесятые.
Практика — Clean, например, восьмидесятые.

В целом с посылом статьи согласен. Но, из того с чем сталкивался, Rust, всё-таки, внёс новую парадигму. А именно концепцию владения. Я так понимаю, это побочный эффект от системы управления памятью, но она довольно сильно влияет на базовые принципы построения программы.

Это совершенно не новая парадигма, это базовая концепция программирования. Единственное новшество раста в автоматизации проверки правил и их математической строгости. Не знаю, делал ли подобное кто-то до него на таком уровне.

Но это довольно значительное новшество для промышленного ЯП. А до раста такое делали в Cyclone.

Виртуализация возможна и без VT-x, просто накладные расходы выше.
Ну вот, а TS говорит, что развития нет.

появление Vx, Gpu итп - это не мира программирования достижение

А что, мир программирования какой-то обособленный от остальной части индустрии? Или вы выдумали аргумент, что есть какой-то особый "мир программирования", в котором ничего не меняется, а всё остальное — это какой-то другой мир, там может и меняется, виртуализация появляется, новые вычислители (*PU и всякие асики), новые методы и традиции организации всех этих вычислений и организации работы и взаимодействия как в команде, так и между компаниями, но причём тут программисты, да?

Да даже если говорить про программирование, особенно про олимпиадное программирование и оптимизацию, за последние 50 лет появились чуть ли не половина самых оптимальных алгоритмов для всех видов задач, в особенности для больших данных.

Ну да, и такие ребята, отрицающие существование прогресса обычно ещё пренебрегают тем, что 99% работы и "новизны" содержится в миллионах мелких инженерных мелочей, без которых "основные принципы" пятидесятилетней давности — не более, чем благие пожелания.

появление этих алгоритмов доказывает концепцию ускоряющегося поезда, за которым не угнаться?

Скорее расширяющегося фронта, растущей поверхности надувающейся сферы — отрасль растёт и можно прекрасно угнаться за своим кусочком, но этот кусочек составляет всё меньшую и меньшую долю поверхности с каждым годом.

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

Никаких новых знаний для возвращения в отрасль ему не потребуется. Ну да, новые фреймворки какие-то появятся. А вот новых парадигм не будет. От слова "совсем"

Вы точно из этой отрасли? Здесь на пару лет пропадешь и все, ты пропустил CI/CD, kubernetes, docker, облака, serverless, TDD и миллион других парадигм построения софта. Для возвращения в отрасль ему надо будет осваивать все это, иначе этого динозавра только на джуна посадят, ибо он не знает даже как софт деплоить правильно.
Все это изучается примерно за неделю-две. На уровне пользоваться процессами которые другие построили.

Новый фреймворк учить и то дольше.
за неделю-две. На уровне пользоваться процессами которые другие построили.

А строят это какие-то неземные люди, которым это знание при рождении дано?

Почему? Те кто не проспал последние 10 лет и построили. Перестраивать ежедневно не надо, надо просто использовать уже готовое.

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

Годами чтобы апишки вызывать? Или чтобы стейтлейсс апишки делать начать? Или балансеры сделать?

Сеньер проспавший 10 лет концепцию за день поймет. Неделя-две это чтобы до среднего по рынку уровня дотянутся. Там все совсем просто же. Все концепции известные и старые, а то что обозвали по другому и обернули во что-то это мелочи.

А жутко переусложненный кубернетис никто и не понимает на самом деле. Не зря всякие обертки так популярны. Они простые. Тоже деь-два на разобраться.
Да простой он на самом деле, там архитектура простая, аж завораживает. Но сверху налепили… + родовые болячки тянут, и названий своих напридумывали. А так на 2 дня почитать, пару недель попользоваться. И уже можно в чатике по теме гуру быть.
Годами разбираться как эффективнее строить те или иные приложения. Как строить архитектуру системы, чтобы она лучше жила в кубере. Как настраивать деплой, автоскейлинг, сбор метрик, логов. Как работать с хранилищами, базами. Я не знаю, вы или невероятный эксперт, что вам кажется просто, или сами не знает и доли возможностей кубера. В нем очень много возможностей и настроек. И все они так или иначе влияют на архитектуру приложений.

Какие обертки? Все мне известные дистрибы это не более чем по-другому упакованный кубер с идентичным функционалом полноценному — k1s, k3s, kind. Все это одно и тоже просто с разным набором встроенных «плагинов». Они проще полного кубера только деплоем. k3s банально один бинарник запустить, внутри которого вкомпилены все части обычного кубера.
Как строить архитектуру системы, чтобы она лучше жила в кубер

Что вы там эфективнее строить собрались? Любой хайлоад это балансеры и шардирование. И любимые тут алгоритмы. Как и 10 и 20 лет назад. Уже тогда умели и балансировать и шардировать. И даже алгоритмы писать умели.

Мониторинги были всегда. Лет 15 назад точно. Скорее и раньше. Все были в курсе что за софтом надо наблюдать. Это не зумеры придумали.

Как настраивать деплой, автоскейлинг, сбор метрик, логов. Как работать с хранилищами, базами. Я не знаю, вы или невероятный эксперт, что вам кажется просто, или сами не знает и доли возможностей кубера. В нем очень много возможностей и настроек. И все они так или иначе влияют на архитектуру приложений.

Со стороны разработчика возможности не нужны. Вот сюда пихаем метрики, вот сюда логи, вот мой образ для деплоя (от deb пакета отличия не сильные на самом деле). Он стейтлесс, можно ребутать сколько угодно. Ставить за балансером, желательно с липкими сессиями. Ожидаемое потребление ресурсов вот такое.

На этом примерно все. Остальное мелочи не играюшие роли при написании кода. Если вдруг понадобится открываешь доку и читаешь за час.

Какие обертки?

Обычно упрощающие. Типа OpenShift.
Скажем так, все кубики из которых строится кубер я использовал еще до того как он появился. Сложного я в нем ничего не вижу. Для использования k8s разработчиком знаний не много нужно, администрировать кластера — тут по больше, но объем знаний тоже не сильно большой (если знаешь кирпичи из которых он сделан)
А так называемые обертки, это CRD, их действительно много всяких разных.
И если вернуться к вопросу «Как строить архитектуру системы в k8s», ну вначале посмотрите как он сам построен ))
Там реально ничего сложного, вас никто не заставляет детально разбираться с реализацией автоскэйлинга, cni, csi и тд. просто посмотрите как устроенно взаимодействие компонентов, куча вопросов отпадет.
Из этой, сразу видно.
Я наверно динозавр (ну почти, всего 44 годика)
В настоящий момент участвую в 6 проектах, как раз учу молодежь CI/CD, Kubernetes, Docker, podman, облака и тд. Стабильно пару раз в месяц вижу как начинают пилить какой то кривой велосипед который давно написан, рассказываю, показываю и экономлю время. Не давно стало скучно, решил опять код пописать, промежуток лет 6 — 7, поменялось несколько версий компилятора, изменились инструменты сборки, добавилось несколько новых фич. Но особых каких то проблем не вижу. Читаешь доки, пишешь, словарный запас пополняется за пару месяцев до приемлемого уровня. Потом просто пишешь.
Прикол этих технологий в том, что они порой принципиально меняют подходы. Как конфигурирует софт, как запускается, где чего хранит, как куда обращается. Мелочей этих миллион, что в кубере, что вообще в облаках. И просто по докам и пару месяцев работы ничего не освоишь от слова совсем. Понятно, как писать цикл for или как отсортировать массив за 10 лет не поменяется никак, но нынче задачи программиста все же намного шире стали. Поэтому выпав на несколько лет из отрасли можно оказаться у разбитого корыта, когда ты вроде умеешь код писать, только этого совсем недостаточно.
А вот тут не согласен. 15 лет назад в трэнде был живой переезд процесса (виртуальные машины и openvz умели, да и сейчас умеют)
Потом появился докер, микросервисы и все такое.
Вроде новое, но вот не совсем. «Девиз» erlang «let it crash».
Все эти микросервисы и прочие это развитие этой идеи.
И вот если честно куберу до erlang еще далеко. Но там можно писать на чем угодно, тем и берет.

Изучить кубер разработчику это потратить 3 дня на чтение + пара недель опыта работы с ним. Знать вот всю структуру данных которая описывает deploy или sts или ingress можно конечно, но обычно смысла мало.

Вот вопрос, что проще написать спеку для сборки rpm(deb) пакета
или Dockerfile?
А ответ на вопрос и раскрывает тему почему docker выстрелил. k8s кстати не факт что будет жить долго. Как то слишком сложно для «5 бинарей»
И вот это сложно эт не мое, это по опыту внедрения.
CI/CD, TDD

субкультура Perl, cpan, всё это было ещё в 90-е


kubernetes, docker
про них есть в статье

облака, serverless
это всего лишь способы инкапсуляции
Вот кстати nix эт прям белая ворона в этом стане, но технология красивая, там лоск сделать кубер, ansible, teraform забудут.
Эти способы инкапсуляции меняют процесс написания приложений и принципиально влияют на архитектуру. Вы хотя бы прочитайте о чем пишите.
Вы стали джейсоны по другому перекладывать?

Был xml, стал json.
Был Оракл, стал Потгрес.
Стейт писали на диск в файлик, сейчас пишем в подходящую базу.
Логи писали в syslog, сейчас в stdout пишем.
Метрики писали на диск, сейчас в апишку какую-то.
Вот, очереди всякие добавились работающие из коробки. Это удобно.

По сути ничего не меняется уже много лет. Все знания адаптируются вообще без проблем.

Вернуться в ту же область, делать те же самые задачи конечно получится и даже вообще без каких-либо изменений, ведь у нас всё только добавляется, старое никуда не девается, да. Разве что придётся через 15 лет поскрипеть мозгами, чтобы университетский курс вспомнить-то :) А то, что "парадигм" новых не будет — так парадигмами знания не ограничиваются. Приведу аналогию — все необходимые знания по боксу можно в одном учебнике описать, но вот ставил бы я на Тайсона, а не на выпускника университета, выучившего этот учебник. Хотя казалось бы, вот она, информация, ничего нового.

Именно его и достижение. Нейронные сети — это основный двигатель прогресса гпу сейчас. Виртуализация — ее двигало развитие софта в целом, повышение его сложности. Железо не развивается само по себе, оно всегда отвечает потребностям чего-либо.

Прогресс заключается не только в появлении новых инструментов, но и того где и как они примнняются.

©: 'Контрреволюционные вещи говорите'.
Так можно договориться до того, что, выше уровня гостьарбайрера не поднимешься, сколько иностранный язык не учи.

И да… в бухгалтерии надо учиться больше и чаще: за последние двадцать лет план счетов дважды поменялся и каждый месяц регуляторы придумывают новые изменения, обязательные для исполнения. За программирование на 'старых' парадигмах штрафуют, как, например, налоговая за нарушения в бухгалтерии?
В терминах той поговорки про оптимиста, пессимиста и стакан воды ваша статья сводится к фразе «стакан уже не тот...»

Скорее, "стакан все тот же уже 50 лет":)

А как все вышесказанное нивелирует тезис, написанный в начале статьи о том, что «программирование - это такое место, где всё постоянно развивается, и, стоит только отвлечься на полгодика, как ты перестаёшь быть специалистом и прям ну просто никуда уже на работу не устроиться. Дескать, работа программиста - это постоянная учёба. Учёба всю жизнь. Постоянный бег за всё ускоряющимся поездом»?

Если технология была придумана 60 лет назад, а получила распространение лишь сейчас - это же не значит, что она не развивается или что ее не надо изучать. Да, если «асинхронщину» придумали в нулевых, а востребована она стала лишь сейчас, то ее нужно изучать, точно так же со всеми технологиями, и это доказывает, что «программирование - это такое место, где всё постоянно развивается». Может быть все современные технологии и не новы, но их релевантное изучение и применения в тех областях, для которых они не были задуманы, это ли не развитие! И если вчера ты сидел вставлял перфокарты в компьютер, то сегодня ты уже никому не нужен, если не будешь постоянно обучаться «неновым » технологиям

В статье все правильно написано, но, как мне кажется, это все пустые рассуждения, ведь даже если абстрагироваться от программирование, то можно было сказать, что вот, мол, математику 3000 лет назад придумали, а на ее основе все точные науки созданы... Но это же не корректно

Давайте так, тут есть выбор, учиться или нет.
Ну и у врачей он есть, только сильно жестче.
У строителей, аналогично жестче.
И тут можно вписать кучу профессий.
И будут ли IT специализации на вершине сложности, вопрос весьма провокационный с учетом топика. Что собственно и наблюдается.

В тот период развивалось не программирование, а технология программирования. Писать большие и сложные программы быстро и более-менее качественно – вот что было важно.


Все остальное было компенсировано экспоненциальным развитием хардуера.


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

Программирование развивается, но куда то не туда, как и все остальное в общем то
Безусловной новинкой является язык Go. Включивший в свой синтаксис средства коммуникации между потоками/процессами

 % Create a process and invoke the function web:start_server(Port, MaxConnections)
 ServerProcess = spawn(web, start_server, [Port, MaxConnections]),

 % Create a remote process and invoke the function
 % web:start_server(Port, MaxConnections) on machine RemoteNode
 RemoteProcess = spawn(RemoteNode, web, start_server, [Port, MaxConnections]),

 % Send a message to ServerProcess (asynchronously). The message consists of a tuple
 % with the atom "pause" and the number "10".
 ServerProcess ! {pause, 10},

 % Receive messages sent to this process
 receive
         a_message -> do_something;
         {data, DataContent} -> handle(DataContent);
         {hello, Text} -> io:format("Got hello message: ~s", [Text]);
         {goodbye, Text} -> io:format("Got goodbye message: ~s", [Text])
 end.

Пример из Википедии синтакса Эрланга, появившегося в 1986 году. Обратите внимание на восклицательный знак и управляющую конструкцию receive.

Только про паттерн матчинг не упоминайте )).

Самый существенный прорыв в IT — резкое снижение до нуля порога входа за последние годы.

Можно поспорить, что порог входа в программирование наоборот вырос до небес в последние годы. Раньше было как? Включаешь компьютер, хоп, вот тебе и бейсик или турбопаскаль или даже какой-нибудь делфи, visual C++ и т.д. Написал программу, запустил, работает, все ресурсы компьютера в твоём распоряжении. А сейчас? Что-то нетривиальное (больше hello world'a) запустить, это нужно повозиться, если локальное приложение — гемор с установкой среды разработки, локальными разрешениями на всё подряд (а чего это ты запустить пытаешься?), зависимостями (помним, речь про нетривиальное приложение); кто скажет, что в браузере легко чего-нибудь запустить — тоже давно не смотрел глазами новичка на этот процесс, а уж про всякие облака — вообще молчу, количество телодвижений и приседаний для того, чтобы просто запустить хоть что-нибудь — невероятное.

Поддерживаю. Нулевые вообще были золотым временем в IT. Веб-разработка (front-end) — раньше что у нас было? Верстка на HTML и CSS, JavaScript и самое сложное — jQuery. Сейчас — NPM, YARN, Webpack, Gulp, Grunt, Babel… И это уже не говоря об обязательном знании как минимум 3-х основных JS-фреймворков (Angular, React и Vue). Java-разработка — мне для получения первой работы достаточно было Java SE и Томката с сервлетами. Сейчас от джуна ожидают владения Spring'ом (огромный фреймворк, который не выучишь за пару месяцев — к тому же требует знания Beans, что никак не для начинающих) и Hibernate (со всеми его тонкостями вроде уровней кэширования). А миддл должен знать брокеры сообщений, Elastic Search и Solr, Docker и Kubernates, Hadoop и Akka… Не знаешь чего-то — проваливаешь собеседование. Обучать тебя за свой счет как в начале нулевых нет желающих.

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

Да и видели мы этот код, написанный человеком, который "просто выучил С".

Я просто не представляю, как можно писать хорошие программы с точки зрения качества кода, архитектуры, дизайна системы и тп не имея хотя бы 5 (а лучше 10) лет постоянного решения таких задач. И, главное, решения проблем, порожденных ошибками в дизайне системы.

При том, что в институтах этому не учат и даже не говорят об этом. В лучшем случае расскажут про паттерны gof, которые суть частные случаи.

Если человек просто выучил С, но при этом плавает как рыба в контексте «домена» разработки, он на порядок более ценен чем тот кто знает фрэймворки и тд, но не владеет областью которую описывает.
Далеко не факт. Что с этим человеком делать? Пишет он херню, значит интегрировать в приложение его код нельзя. Такие люди может оказаться эдакими советниками и исследователями. Они описывают доменную зону, кодят какой-нить кривой псевдокод на своем си или еще чем, а потом нормальные программисты это адаптируют в продукт.
НЛО прилетело и опубликовало эту надпись здесь
Он может читать и понимать код написанный другими (более профессиональными) разработчиками, он может им описать контекст области разработки им понятным языком, он может говорить с профессионалами из 2 областей зачастую перпердикулярных знаний на одном языке.

Ну знаете вы 30 фрэймворков, за плечами у вас 10 лет профессионального програмирования, работали например на финтех все 10 лет, в RTB придите, там уже контекст сильно другой, начиная с терминологии. И подходы там уже сильно другие. А это в принципе не сильно отдаленные области. Медицина или строительство уже сильно дальше, а там тоже автоматизация нужна, и не на уровне давайте склепаем вебсайтик с рекламой нашей клиники.
НЛО прилетело и опубликовало эту надпись здесь
У всех свой опыт. Квалификация менеджеров бизнес аналитиков и тд играет не маловажную роль. Скажем так, с моей спецификой приходится погружаться в контекст достаточно сильно, и разговаривать как с владельцем так и с разработчиками.

Мне в почту пришло несколько редакций сообщения, вот разработчик встраиваемых систем это уже достаточно узкая специализация на мой взгляд, как правило задачи в этой сфере четко сформулированы именно профессионалами в контекстной области, а так далеко не везде.
Человек делает прототип который устраивает заказчика и решает его проблему, но оставляет желать лучшего с точки зрения стабильности и качества, потом этот код переписывается профессионалами которые плюются от кода, но вполне понимают что должно получится в итоге. Итеративный процесс вроде получается? только количество итераций уменьшается.
Я не думаю, что он сделает прототип, который устроит заказчика. Максимум, он напишет proof-of-concept для своей же команды. Люди посмотрят, возьмут суть алгоритмов и напишут вокруг рабочее приложение. Количество доменно-зависимого кода почти в любом программе довольно минимально. Уже много раз упомянутый финтех. От финансов там раз два и обчелся. Основная суть там это биг дата, HFT и прочие злые штуки. Знания С и фундамента для этого недостаточно.
Ну С тут условный, скорее какой нибудь питон с jupiter ом. ))
Код делает то что надо, но совсем не в тех количествах. И разработка уже дальше перепилит, чтоб оно молотило не 100 мегабайт за час, а пару терабайт и в параллель на нескольких машинах.
У меня в примере прям сейчас пара контор где по несколько аналитиков сидят, строят модели и тд, но вот их код… Делает то что нужно, но запускать нельзя. У каждого своя песочница. А когда это надо встраивать в основной сервис, их proof-of-concept-ы просто переписываются на других языках.

Формализовать сразу без их участия, ну практически не реально, канал связи маркетологи <-> разработка наверно возможен, но ни разу нормального не видел, писать сразу нормально просто бессмысленно, там 80% теорий просто не срабатывают.
У меня в примере прям сейчас пара контор где по несколько аналитиков сидят, строят модели и тд, но вот их код

У нас тоже самое. Эти люди даже не код пишут, они пишут модели. Это основной полезный выход от них. Некоторые даже в экселе это делают.

Формализовать сразу без их участия, ну практически не реально

Для этого все же другие люди есть, а не старперы с СИ и питоном. Руководители проектов, архитекторы, тимлиды. Люди, которые не сегодня просунулись, а имеют богатый и актуальный опыт.

Да да конечно. Когда я начинал можно было взять делфи или php накидать за вечер сайт на коленке или приложение которое делает простейшие запросы к БД и ты программист которого возьмут на работу.
Сейчас что бы устроится джуном нужно выучить кучу либ помимо ЯП, гит, докер, научится писать тесты, прогонять код каким не будь сонаркубом, научиться работать в команде и использовать API и брокеры сообщений. И прочее прочее. Честно как все это учить с нуля и что именно надо учить я не представлял бы если бы уже 10 лет в IT не работал.

либы изучаются по мере работы: важны знания общих принципов, которые хз сколько уже не меняются и не развиваются.

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

API и брокеры сообщений - просто способы что-то делать, конкретности знать не нужно, достаточно общих принципов.

Как 10 лет назад были очереди, так и теперь ничего нового

разве что название модной стало другим

API и брокеры сообщений — просто способы что-то делать, конкретности знать не нужно, достаточно общих принципов.

Нет, ну точно вы будто мимо проходили, а не работаете в этой области. Ничего знать не нужно. Расскажите это кафке, которой 10 лет назад не было. Расскажите это NATS (или еще круче zeromq), который кругом брокером кличут и с рэбитом сравнивают. Их тоже 10 лет назад не было. Или вообще любому брокеру, когда вы сколько-нибудь большую нагрузку на него создаете.

Я тогда не удивлен, что вы согласны, что можно внезапно выпасть из спячки и продолжить работать как ни в чем не бывало. Если ничего не изучать, не осваивать, а по верхам доки, да вики читать, то конечно. Были 5 лет джуном, так им через 10 лет и останетесь с таким подходом.

я говорю что достаточно знать принципы базовые

и поскольку они не меняются, то возврат в отрасль крайне дёшев

Расскажите это кафке, которой 10 лет назад не было. Расскажите это NATS (или еще круче zeromq), который кругом брокером кличут и с рэбитом сравнивают. Их тоже 10 лет назад не было.

10 лет назад мы применяли бинстолк, тарантул для очередей

всех тонкостей: может ли продюсер класть таски пачками и кто удаляет таску при её выполнении. ну может ещё о масштабировании какие-то базовые знания

допустим проспали 10 лет, проснулись

появилась кафка

вопросы будут какие драйвера для них юзать из клиентского софта, да что лучше задаче подходит

кафка и зиро не сделали революции в очередях, а Тарантул, так и вовсе на месте: скорее всего написанное 10 лет назад - на нём и теперь пойдёт

что тут непреодолимого?

либы изучаются по мере работы: важны знания общих принципов, которые хз сколько уже не меняются и не развиваются.

Нет. Это в нулевых так было. Сейчас же нет филантропов, желающих обучать тебя за свой счет. Все ждут готовых специалистов, со знанием вороха фреймворков, а не «общих принципов». Вот мне на многих вакансиях по Java отказывают — потому что нет опыта работы с брокерами сообщений. Коммерческого опыта, конечно — pet проекты никого не интересуют.
Все ваши примеры исходят из одной и той же некорректной логики. Вы берет идею в ее самом примитивно объяснении с википедии и заключаете, что ее изобрели десяток лет назад и до сих пор ей пользуются, а значит ничего нового.

Давайте возьмем нейронные сети. Ваше определение не имеет ничего общего с текущим прогрессом в них. Да, их изобрели очень давно и так же очень давно забросили, потому что люди не увидели пользы. Но вот внезапно сейчас нейронные сети у нас научились делать похоже все. И причин тут две, но они взаимосвязаны — научный прогресс в архитектуре сетей и прогресс в железе. Старые нейронки были примитивны в своем строении — пара слоев там да сям и херачим ее входными данными, пока не родит что-то. Сейчас огромные усилия прилагаются для построения сложной архитектуры сети со слоями специального назначения. Ничего подобного раньше не делали, а если и делали (я тут не авторитетный источник), для этого банально не хватало вычислительных ресурсов. Обучить модели такой архитектуры огромная по сложности задача. Вокруг этого выросли целые индустрии, которая толкает прогресс видеокарт, ускорителей ИИ, интерконнектов. Термин deeplearning не случайно придуман.

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

Да и количество разных трюков, необходимых, чтобы все эти сети учились — огромное. Глядя на многие из них, легко впасть в заблуждение, что это не прогресс: какой-нибудь резнет — это что большое достижение что-ли, прокинуть копию данных в обход слоя?! Или дропаут — одна строчка кода, чтобы выкинуть половину данных случайно. Или модные оптимизаторы — добавляем в уравнение новый член и получаем чудесное улучшение. Или инициализация весов — мелкий коэффициент, грубо говоря "делить на два", улучшает сходимость принципиально.


Однако, без всех этих улучшений все эти перцептроны и не работали, даже не смотря на то, что "к 90-м годам в этом области уже были десятилетия опыта", а сейчас работают. И самое смешное, что с полученным новым опытом оказывается, что и старые подходы можно заставить работать не хуже (пару месяцев назад был взлёт как раз обычных перцептронов в компьютерном зрении, когда переосмыслили их через развитие свёрткок и трансформеры).


Ну и так по всем пунктам — да, "идеям" десятки лет, но в физическом мире существуют не идеи, а реализации. От идеи паровой машины, до реализации — тысячи лет прошли, как и от атомов, до атомных реакторов. Так же и в программировании — описать как в теории система компьютерного зрения будет работать можно хоть в 50-е, ещё до появления толком самих компьютеров, а получить рабочую систему — в 2010-е и в процессе придётся таки поучиться самым разным вещам (банально, кто мог предположить, что для ускорения всех этих нейронок придётся десяток новых форматов чисел с плавающей точкой изобретать?!).

Или дропаут — одна строчка кода, чтобы выкинуть половину данных случайно

Только не данных, а связей, ну да ладно. Тут сам собой вспоминается рассказ Воронцова (евпочя) с лекции в стенах ВЦ РАН об optimal brain damage. 90-й год.


Хм, только сейчас заметил, что там ЛеКун в соавторах.

Optimal brain damage больше на дистилляцию современную похоже. Однако же, несмотря на приличную теоретическую составляющую ("information-theoretic ideas, Vapnik-Chernovenkis complexity, бла-бла-бла") и внешнюю похожесть, техника тогда не дала хороших результатов и свежим взглядом видно, что понимали они нейронки совсем не так, как сейчас ("известно, что с ростом сети, тренируется всё хуже, генерализация страдает, ...").


PS: а вообще, такие исторические статьи — чтиво забавное. И написаны очень просто (вот уж пример отсутствия новых парадигм в конкретной статье) и то самое количественное развитие в глаза бросается ("наша довольно здоровая сетка на 2600 параметров") и то, что они думали будет важным из этого ("вот этот наш метод использования второй производной можно будет ещё огого как применить").

Прикол: Ответы на вопрос в статье (в виде опроса) покажут результат 62/38 (или золотое сечение).
«Программирование — это отрасль, в которой надо постоянно учиться», «Отставание на полгода примерно то же, что и выпадение из отрасли навсегда»,

И это тоже верно и неверно одновременно.
С моей точки зрения (инженер систем, не программист) сейчас практическое программирование в основном построено на неформальном знании множества ошибок, обходных путей, «особенностей реализации» всевозможных программных систем. То есть систем, описанных некими семантическими методами.
В инженерии разных систем очень давно все это существует и применяется. И классы, и объекты и аспекты. IDE программирования (например, типа Eclipse) — с точки зрения инженера так себе инструмент для построения сложных систем. В электротехнике давно решен вопрос с представлением систем в виде совокупности диаграмм — текста и взаимного преобразования туда-обратно (пример: ePlan). Визуальное программирование (проектирование) сложных систем — на уровне инженерии это давно так и удобно реализуемо. Единая классификация и обозначение функций, объектов, локализации, объектов в разных аспектах — давно реализовано на уровне стандартов (IEC 81346).
Полиморфизм объекта как совокупности и единства трех аспектов «функция-продукт-локализация» в одной сущности — тоже там же. Плюс любое количество одновременно используемых аспектов в такой классификации, плюс все это живет во времени (цикл жизни и изменения элемента в системе). Да еще объект может быть одновременно участником разных циклов жизни в разных своих аспектах.
Много чего в инженерии взято из программирования, много чего перекочевало наоборот из инженерии в программирование. Всегда есть взаимосвязь. Инженерия обычно связана с менее детерминированными системами из реального мира, чем программирование, хотя и не всегда. Обычно делается некая мета-модель в виде диаграмм PID, PFD и подобных и по ним уже строится модель программы для управления процессами. Но при построении целого завода (как системы) и разработке таких диаграмм нужно всегда думать о реализации софта для управления этой системой. И завод в результате строится по довольно стандартным архитектурам из мира софта (GERAM, TOGAF).
Но вот тут собака и порылась. Система спроектирована в виде диаграмм и рисунков (основа) и добавлен текст (обычно как дополнение). И потом эти схемы и рисунки с трудом и кряхтением соединяются с модулями софта. UML — да, почти все на нем в инженерии построено (в том или ином виде). Безшовное преобразование UML в код программы — ну кое-как и со скрипом. А обратно и поддерживать синхронизацию — уже трудно.
Поэтому мое ощущение, что несмотря на огромное развитие технологий IT ( я же как инженер использую именно IT продукты для разработки и построения систем), последующее воплощение систем в реальности — реализовано на старых и не очень эффективных методах.
С другой стороны, визуализация информации, интерфейс и логика работы в промышленных и IT системах такие, что без слез не взглянешь на убогие SCADA кривуляки.
Ну а про слабое развитие «всего остального» кроме императивного подхода — совсем вбивает в грусть. Мне то лично и нужны именно декларативные системы описания и выполнения для построения реальных систем из железа. Они лучше подходят для работы. Но есть то, что есть (как правило императивный подход), от и приходится более 40% времени в проекте тратить на решение проблем коммуникации.
С моей точки зрения вопрос не в языках или концепциях, а в их неравномерном развитии.
Декларативные языки имеют множество объективных проблем, которые и не позволили им прижиться за пределами узких сфер, где они работают. SQL например.
SQL например.

Ага. Но это очень специфическое применение.
Для анализа-синтеза сложных систем, если на начальном этапе многое не понятно — декларативные подходы работают лучше. Если бы можно было в начале цикла проектирования использовать декларативный подход (pre-planing концепция в том же ePlan), а потом соединить его с императивными модулями (на уровне электротехники так сделано) — то было бы счастье. Это сделано в ePlan, но только частично, и в одну сторону. Потом нужен огромный (и тупой) труд программистов по преобразованию в код. Как бы два мира: инженеры делают в одном мире все, потом все переводится в софт. Криво и косо, долго и дорого.
Я и пишу, в узких сферах, потому что больше нигде декларативные языки на практике себя не показали лучше императивных. Можно много пытаться искать оправдания и заговоры, но факты нам говорят, что для общих задах императивные языки лучше всех остальных. Самый реальный конкурент у них из декларативных это функциональные языки. Сколько десятилетий прошло и они не могут ничего противопоставить. Люди ими пользуются, пишут продукты, но живут в очень узких маленьких нишах и даже не собираются из них выбираться. Реальная польза от них это развитие науки в целом и тестовая платформа для новых подходов, которые потом стабильно перетекают в императивные языки.

Вообще то наоборот, с развитием компиляторов и ЯПов декларативное программирование становится всё популярнее. Функциональщина или там rx например - крайне декларативны и как раз лет 5 назад начали проникать в массы.

Я этого не вижу. Я вижу стагнацию функциональных языков и перетекание отдельных небольших фич в императивные языки, но не более. Сами декларативные языки, по сути, стоят на месте в плане проникновения. Я выше поэтому и написал — реальная польза от них это развитие науки в целом и тестовая платформа для новых подходов, которые потом стабильно перетекают в императивные языки. На большее функциональные языки пока рассчитывать не могут, а все остальное это специализированные решения — SQL, ansible, CI.
Почитайте про extensible effects. На базе одной этой идеи целый язык программирования сделали, just for fun, и не ожиданно комьюнити организовалось, пилят, без вливания денег гуглом.
А про проникновение, как учат в той парадигме и программируют.

на Haskell похоже, прям один в один...

Там есть разница, ключевая именно по организации эффектов.
А база да, haskell, выкинули легаси, добавили свои плюшки.
component :: forall props eff. ReactClass props -> props -> Eff ( ajax :: AJAX, console :: CONSOLE, dom :: DOM | eff ) Unit
component app props = (container >>= render ui) *> return unit
  where
      ui :: ReactElement
      ui = D.div [ P.className "root" ]
                 [ createFactory app props ]

очень старый кусок кода, из IO мне нужны эфФекты AJAX, пнуть сообщение в консоль, модифицировать DOM
В сравнении со стэкированием монад в haskell это сильно проще, ниже порог входа кардинально.
Я прям наблюдаю за развитием проекта, не давно понадобился дашборд к github
и неожиданно нашел готовый на этом языке. )

Почему? Я бы не сказал, что в функциональщине стагнация, или что на большее они рассчитывать на могут.

Языки со строгой типизацией набирают популярность. Как приятно работать компилятору, если программист за него сделал кучу работы! Но несёт ли эта технология что-то новое?

А разве нестрогая типизация появилась не позже строгой?

Нестрогая — LISP, строгая — Fortran, практически ровесники.
Согласится с автором, в том что ЯЗЫКИ программирования и структуры данных не имеют революционных достижений, можно, и я соглашусь.

Но в статье пропущены революционные ТЕХНОЛОГИИ создания маленьких программ и больших программных комплексов, которые изменили IT-ландшафт в глобальных масштабах.

Во-первых: открытый код, следствием является сборочное (из библиотек) программирование на потоке.
Во-вторых: гибкая философия разработки (agile в совокупности), итеративное программирование с постоянной обратной связью.
В-третьих: конвейерное программирование (непрерывная разработка), фабрика программного продукта с технологическим контролем и выходной приёмкой.

IO монада изобретена относительно недавно. Immutable vector 10 лет как описали алгоритм.

То, что они редко где применяются - другой вопрос

а пайп как давно изобретён?

Ritchie & Thompson, 1974.

и что в итоге ?

В итоге он есть почти в любой железке.

А причем к моему комментарию пайп?

Timsort вот довольно свежий, концепция линейных типов. А в будущем нас ждут завтипы. Это нормально, что академическая наука на десятки лет впереди индустрии. Легко говорить о том, что все придумали лет 40 назад даже не зная о том, что сейчас творится на острие науки.

Timsort вот довольно свежий

1993 год. Всего 28 лет. Свежий.

Timsort is a hybrid stable sorting algorithm, derived from merge sort and insertion sort, designed to perform well on many kinds of real-world data. It was implemented by Tim Peters in 2002 for use in the Python programming language.

Чему верить? Википедии или странному комменту.

Просто чуть дальше википедию прочитать.
It uses techniques from Peter McIlroy's 1993 paper «Optimistic Sorting and Information Theoretic Complexity».[10]

Научную работу в 1993 уже написали. Дальше просто никому не надо было, вот и не реализовывали. Профит понять не смогли раньше. Как и многое другое.

По-моему неправильно поставлен сам вопрос. Не "что мы изобрели" нужно спрашивать, а "какую проблему мы решаем".

к сожалению, далеко не всё направлено на решение проблем
Могли бы привести пример?

Абсолютно соглашусь с автором! Только кое-что хотелось бы дополнить: основное развитие в IT по моему мнению, состоялся именно в hardware части, которая и открыла возможности эффективного применения концепций программных технологий и методов, открытых в 50-70х годах (золотые годы информатики). Покуда железо не перейдет на радикально новый способ обработки радикального новой информации ( и тут прорыв сулят кубиты и квантовые технологии), до тех пор мы будем экстенсивно развивать уже придуманное.

Закон Мура уже замедлился, а так да, если не изменят физику процесса, то начнут подтягивать программную часть ))

Закон Мура примерно 10 лет как не работает вообще. Конечно, хардуер все еще усовершенствуется, но уже нельзя просто так написать медленную программу и ожидать что через какое-то время, она будет работать достаточно быстро. А раньше так можно было.

Закон Мура и не обещал прирост скорости, только экономичность прироста транзисторов (что удачно совпадало с ростом производительности долгое время). Транзисторы и сейчас наращиваются, а вот с (однопоточной) производительность беда, да.

(что удачно совпадало с ростом производительности долгое время)

Это не "удача" а совсем закономерное явление. Формально можно назвать его "Закон Хауса":


The doubling period is often misquoted as 18 months because of a prediction by Moore's colleague, Intel executive David House. In 1975, House noted that Moore's revised law of doubling transistor count every 2 years in turn implied that computer chip performance would roughly double every 18 months[30] (with no increase in power consumption).[31] Moore's law is closely related to MOSFET scaling,[19] as the rapid scaling and miniaturization of MOSFETs[7][32] is the key driving force behind Moore's law.[19][8] Mathematically, Moore's Law predicted that transistor count would double every 2 years due to shrinking transistor dimensions and other improvements. As a consequence of shrinking dimensions, Dennard scaling predicted that power consumption per unit area would remain constant. Combining these effects, David House deduced that computer chip performance would roughly double every 18 months. Also due to Dennard scaling, this increased performance would not be accompanied by increased power, i.e., the energy-efficiency of silicon-based computer chips roughly doubles every 18 months. Dennard scaling ended in the 2000s.[20]

И если так, то да – закон Мура все еще работает. А закон Хауса, который ИМХО намного важнее для программистов, закончился.


Так что от оптимизации нам не уйти никак. :P

Ну да, я скорее про восприятие говорил — в головах у людей закон мура заменяет все остальные "законы" масштабирования — Денадра, роста частоты и тд. А от оптимизации не уйти в любом случае.

Автор, а что для Вас значит «программирование развивается». Новые языки для Вас не развитие, развитие существующих языков тоже. Эдак можно вообще всё к машине Тьюринга свести и сказать, что да, вот там был прорыв, а с тех пор никакого особо развития.

Новый язык не дающий новых качеств — это вкусовщина


Языки Perl, Python, Php, Ruby, Java, C#, итп — всё языки ровно одного и того же класса задач.
Переход между ними — просто мода и вкусовщина.


то же с Go, C++, и прочими компилируемыми

Perl и Java это языки одного класса задач? Серьезно?

А можно тогда Ваше определение «новых качеств» ЯП узнать?

Что можно делать на Java, чего нельзя на Perl?
Что делают на Java чего не делают на Perl?

НЛО прилетело и опубликовало эту надпись здесь

Вот! Тьюринг-полный язык.


А дальше? Вот насущно у нас сейчас что? Утилизация CPU. Go — выдаёт вариант для этой утилизации. Ничего нового, но всё же попытка. Окей.
Что у нас ещё есть? GPU.


Какие наработки по языкам с более внедрённой/прозрачной параллельностью?


Вот например язык VHDL. "Всё параллельно". Кто-то пытался адаптировать такой подход под современное программирование? Нет


как 25 лет назад писали мьютексы и каналы, так и сейчас семафоры и очереди.


"и так всё"

Haskell вполне себе дает математически доказуемые гарантии для распараллеливания хоть на удаленных машинах, хоть на локальной и благодаря тому что, он чемпион по возникновению DSL из неоткуда, код можно с минимальными правками запускать хоть на GPU.

код можно с минимальными правками запускать хоть на GPU.

Да, accelerate — прикольная штука.

Вот например язык VHDL. "Всё параллельно". Кто-то пытался адаптировать такой подход под современное программирование? Нет

Но ведь VHDL это вообще язык описания железа, на кой его адаптировать под современное программирование, что это вообще значит?

да железа, но и программы на нем писать можно было, но я не о железе, а о принципе новом, которому пора бы уже появиться

а параллельность - это один из некопанных кусков в плане языков программирования

но пока новые языки сводятся к: тут больше сахарку добавим и вуаля

Reactive programming, не?

Все эти новые технологии программирования, появление новых языков и фреймворков - это конечно здорово. А как сейчас с оптимизацией кода под условно слабое железо обстоит дело?

Вот есть у меня планшет с гигабайтом оперативки - и всё, я не могу им пользоваться для сёрфинга интернета из-за не оптимизированных сайтов и (или) браузера. Доступ к play market тоже превратился в боль.

Или есть Asus eee pc с гигабайтом ОЗУ и 4-мя гигами флеш памяти. Как и какой на него поставить браузер, чтобы не особо тормозило?

Или возьмём современные ноутбуки с целыми 2-мя гигабайтами памяти, распаянной на плате, и ssd на 32 гигабайта, с драйверами только под 64-х битную Windows 10. Как его можно комфортно использовать? При этом лет 12 назад (во времена Windows 7 32 бит или Windows XP) у меня был аппарат намного слабее по железу, и всё "летало".

Я вставил micro-sd карточку на 64 гб, сделал из нее RAID-0 и воткнул mint. Сейчас с него офигиваю с прожорливости сайтов если не отключить у них javascript. А так если брать Haskell или ядро linux то они собираются достаточно быстро)

А зачем RAID-0 на 1 sd карте?

внутрях 32 гб + внешняя 64 = 96 гб один диск с программным драйвером для RAID-0.

Полтора года полет нормальный.

Да уж… )) Старый админ внутри меня тянется за битой…
Внутренний голос успокаивает, это не твои проблемы ))

Ну а как вы хотели? все что у него есть 2 usb, 1 micro-sd (128 гб в пределе), а внутри плата с 2 гб оперативки, ssd который на самом деле 1 микросхема и процессор интел-чери. Это планшет с клавиатурой (у него биус боком запускается), но на него китайцы запихали винду 32-х разрядную. Я его брал как раз для таких издевательств, но сейчас он оказался мне нужен живым

Почему всех так задевает статья?
Я абсолютно согласен с автором. Более того, проработав 5+ лет в разработке, с каждым годом я все сильней ухожу в изучение фундаментала, которому 20-30-40-50 лет, а не того, что показывают на конференциях. Показывают одно и то же. Одна любая идея может кочевать из языка в язык, из фреймворка в фреймворк, эти догоняют тех, итого +- стоим на месте, переиспользуем идеи прошлого.

На мой взгляд, сейчас эра маркетинга.
А Эра героев-первооткрывателей прошла.

Может быть потому, что автор в пух и прах разбивает тезис, который сам же и придумал и навязал воображаемым собеседникам примерами из википедии, что всё уже давно "в принципе изобретено" и на основании этого делает вывод, что ничего не меняется и ничего изучать не надо? А люди из реальной жизни сталкиваются с тем, что всё-таки надо и как-то пытаются объяснить это несоответствие в картинах мира?

Минусующих примерно столько же сколько плюсующих. Так что я не сказал бы что прямо всех задевает :)

Ну тема на поговорить прикольная ))
Да и в каждой шутке есть доля шутки.

map-reduce был вроде только в 2010м опубликован

LISP, лет 70 назад

Нет, так не катит, то что составные части были открыты раньше не означает что все сразу поняли как сложить их вместе. 70 лет назад ни о какой хотя-бы многопоточной обработке в лиспе даже и не думали.
Мне кажется что вы ожидаете каких-то супер прорывов, хотя это так не работает, посмотрите внимательно на историю в датах — все фундаментальные сейчас вещи не были придуманы гением за 7 дней, они были выстраданы годами работы. Тот же лисп который вы приводите 63 года назад был не тем лиспом который можно увидеть сейчас.

Люди до сих пор едят гамбургеры, изобретенные ещё до каменного топора и пьют воду, формуле которой столько же лет, сколько вселенной!

Поэтому ты можешь пососав мамкину титьку и позадротив на приставке стать королем Камчатки!

Да, ещё в махровые девяностые, люди умели сделать кино про жидкого терминатора, но стоило это трёх лет жизни сотен людей и триста миллионов тогдашних долларов!

Да, асинк/эвэйт был ещё во времена царя гороха, но работал он на мэйнфрейме с очередным доступом и был доступен десятку человеков на планете не понятно зачем.

Да, "прорывами" в айти часто называют всякую хрень типа тайпскрипта или джавы а многие вендорные выпуки так и остаются ничем (половина всего что делают микрософто-эппло-гуглы от винформ до обжэктив си и гугл-плюс)

Но поди найди работу на "бейсике со знанием мс-дос ", потому что кремний и во вторую мировую был кремнием а for и if и в бейсике есть!

Это как история про какого-то Кулибина из Урюпинска который в 70-ых нарисовал в тетрадке устройство с "экраном и клавиатурой" и теперь уверяет что "идея Айфона принадлежит ему!"

MS Code, блендер, клип пайнт, нод с электроном и т.п. легковесный софт инновационен не тем , что привносит что-то радикально новое, а тем что создан для реальной работы и развивается тоже отражая реальные нужды реальных людей и технически "всего лишь" компилирует давно известное и проверенное, а не "тратит всего 512 КБ" или "утилизирует классы как никогда раньше" или "софт от создателей матрицы".

В первом айфон не было решительно ничего нового, что уже не было бы реализовано в смартфонах и коммуникаторах до него, но айфон был сделан для аудитории испытывающей хронические трудности с айти вообще.

Атак то да, "нет ничего нового под солнцем и все что есть уже было давно"

Да не, просто автор умеет в софистику, ведь при должном упрощении все уже давно придумано. Космос, электромобили и вообще все к чему мы сейчас потихоньку движемся, стало быть прогресса нигде нет, что тогда он прицепился именно к ИТ вот вопрос?

А что может физически появится нового в парадигме? Оно же основывается на то железо под которое пишется и то как устроено сознание самого твореца, в данном случае программиста. Ничего из этого не поменялось, лишь допиливалось, точно такая же картина скажем в механике, термодинамике, электротехнике и ТД. Всё что можно было сделать из тткрытий, было сделано на их заре, а позже только допиливалось и улучшалось. Так и программирование - это весьма древняя вещь по современным меркам и сейчас лишь дорабатывается.

Языки со строгой типизацией набирают популярность. Как приятно работать компилятору, если программист за него сделал кучу работы!

Однако, странный взгляд! Строгая типизация - это некий договор между программистом и компилятором - программист чётче выражает свою мысль ДЛЯ ТОГО ЧТО БЫ компилятор ему помог найти ошибки на этапе компиляции. Ну т.е. любишь меньше падений в проде - люби и выражаться яснее. (а не любишь - выбирай другой язык, это же просто инструмент)

Автор явно свежие white papers активно не читает, иначе бы не порол чушь.

Статьи из разряда "за последние 25 лет ничего путного не изобрели" были и 25 лет назад.

Принципиально новым мне кажется переход от детерминированного программирования к вероятностному. Вот уж про квантовые вычисления 50 лет назад точно никто в деталях не задумывался и в парадигмы ПО не закладывал.
Мой путь в сферу программирования начался не так давно, хотя закончила универ по данному направлению. Работала в разных сферах, но все не то. Сейчас прохожу курсы по профессиональной переподготовке программистов и все как в первый раз, либо в универе училась плохо, то ли все так поменялось.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.