• Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
    0
    (grammar-nazi-mode компонуются), но по сути согласен
  • Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
    +1
    Когда есть опыт в OCaml и Haskell, высокоуровневые части не кажутся приятными. Слишком громоздко.
  • Реализация «Тетриса» в игре «Жизнь»
    +6
    Оно, конечно, очень круто всё. И мне всегда было крайне интересно, откуда у людей берутся ресурсы времени и деньги на разработку подобных проектов?
  • Google планирует представить облачный сервис для квантовых вычислений
    +1
    Программа — это граф из унитарных операторов и измерений. Можно примерно представлять это себе, как последовательность умножений вектора огромной размерности (2^{число кубитов}) на соответствующей же размерности матрицы. Квантовый алгоритм — это алгоритм, который по входным данным строит такой вот граф из операторов.
  • Google планирует представить облачный сервис для квантовых вычислений
    0
    Я тоже это имею в виду. Там смысл очень простой: сумели поймать в ловушку много атомов (это давно умеют делать), чуть-чуть покрутили некоторые параметры взаимодействия (это новизна) и проинтерпретировали результаты, как симуляцию системы из нескольких спинов специального вида (чтобы грант дали). Сама работа, как физический эксперимент, интересная, но шагом к большим квантовым вычислениям её можно считать с большой натяжкой кота за одно место в ящик.
  • Google планирует представить облачный сервис для квантовых вычислений
    0

    Ну, про 51 кубит старая технология. Ошибок там очень много и, опять же, это не большое произвольное когерентное состояние.

  • Google планирует представить облачный сервис для квантовых вычислений
    +1

    Да можно сделать хоть миллион. Проблема в том, что надо создать 128 запутанных кубитов и оперировать ими как одним целым. В этом проблема. D-Wave так не умеет

  • Google планирует представить облачный сервис для квантовых вычислений
    0
    А какие текущие идеи есть о масштабировании и увеличении числа кубитов? Чё-то как-то ни о каких технологических прорывах давно не слышно. За счёт чего будет 50 кубитов-то?
  • Постквантовая криптография и закат RSA — реальная угроза или мнимое будущее?
    0
    Ну, насколько я знаю, если нужно вычислить дискретный логарифм на эллиптической кривой над полем с 384-порядком, требуется проанализировать 2^192 вариантов. Которые, собственно, и надо все «упихать» в когерентное состояние.
  • Постквантовая криптография и закат RSA — реальная угроза или мнимое будущее?
    0
    В кубиты ничего не записывается. Кубиты, в некотором смысле, «поворачиваются» в нужное положение при помощи унитарных преобразований. А эти преобразования абсолютно точные, потому что работают на уровне физических симметрий (можно вспомнить спектры). Проблема в другом, сложно поддерживать большое когерентное состояние.
  • Постквантовая криптография и закат RSA — реальная угроза или мнимое будущее?
    +1
    Китаев А., Шень А., Вялый М. «Классические и квантовые вычисления» — хорошее введение.
  • Постквантовая криптография и закат RSA — реальная угроза или мнимое будущее?
    +1

    Сможет, если построят достаточно большой КК (нужно 192 когерентных кубита, а пока IBM говорит, что у них есть 16; и не факт, что есть на самом деле). Но для этого могут быть существенные физические ограничения.

  • Telegram и блокировка в РФ: почему чиновники резко изменили отношение к мессенджеру и есть ли смысл его блокировать
    +1
    Тут глупость в том заключается, что они верят, что контроль над средствами обмена поможет справится с угрозой для власти. Что у нас в истории примеров не было что ли? Большевиков хотя бы вспомнить: люди просто собирались вечерком на квартирах и никто не мог с ними ничего сделать. А в нынешние высокотехнологичные времена это ж придётся вообще всё запрещать от точек доступа (потому что есть Гиперборей) до флэшек (потому что есть slacks-net). Способов незаметно передать информацию очень много. И пытаться всё заблокировать — это таких адских затрат потребует и убьёт столько отраслей экономики, что просто страна не выживет.
  • Telegram и блокировка в РФ: почему чиновники резко изменили отношение к мессенджеру и есть ли смысл его блокировать
    +1
    Вы переоцениваете силу интернета. Она, конечно, нарастает, но к выборам вряд ли достигнет настолько критических масштабов. IMHO, всё это больше похоже просто на pr Телеграмма. Вспоминается похожая история о героическом противостоянии Apple и ФБР. Телефон террориста в итоге вскрыли, а Apple подняла продажи в корпоративном сегменте.
  • Система синтеза асинхронных схем Petrify: проблемы и их решение
    0
    Дело не в публикациях, но изложенно совсем не понятно. Вроде, кажется, что-то полезное, но сложно понять, что именно.
  • Почему стоит полностью переходить на Ceylon или Kotlin (часть 1)
    –1
    Сейчас учат Python
  • Почему стоит полностью переходить на Ceylon или Kotlin (часть 1)
    0
    Либо ему просто стало скучно 90% рабочего времени тратить на ковыряние в памяти, указателях и интерфейсах, и он решил выйти на 80-ый уровень искусства программирования.
  • О том, как в Instagram отключили сборщик мусора Python и начали жить
    +1
    Ну, наверное, они достаточно хорошо знают о своих зависимостях, чтобы не рисковать.
  • О том, как в Instagram отключили сборщик мусора Python и начали жить
    0
    Дело не в самой сборке мусора, а в том, насколько она эффективна. В Python за эффективностью никто никогда не гонялся. Ну и, обычно, когда действительно важна скорость, то, скорее всего, Вы просто непишете некий custom-вариант сборки мусора. Размазывать malloc/free по коду тоже не самая лучшая практика для повышения произвоидтельности.
  • О том, как в Instagram отключили сборщик мусора Python и начали жить
    0
    Неясна реальная логика вызова GC в finalize(). Зачем собирать мусор, если все равно всю память при выходе отдавать? Молодцы, что поймали.


    Python же рассчитан на работу не только в операционках с поддержкой виртуальной памяти. Его ещё и просто встраивать можно.
  • Современный подход к сборке мусора
    0
    Пытался, согласен с тем, что неочевидно, как писать производительный код. Но тут акцент был таким: Haskell — язык не самый удобный, но алгоритмы со сложной логикой на нём проще писать, чем на Си++, благодаря сборке мусора.

    Сборка же мусора сама по себе не мешает добиваться высокой производительности и спускаться на уровень ассемблера. Примером может служить GOAL (вообще Lisp), которым до сих пор пользуются в Naughty Dog для программирования игр.
  • ВВС США используют нейроморфный чип IBM для обнаружения танков и наземных систем ПВО
    +1
    Существует эмулятор Compass и MATLAB-библиотека Corelet Library, позволяющи собирать образы из готовых блоков. Было бы интересно узнать и про внутренности самих процессоров, но таких сведений нет. Пока всё описывается уж в чрезчур общих словах для готового работающего изделия. Причастность современных ВВС США только добавляет сомнений
  • Рисуем остаток совы на базе нейросетей
    +1
    Для полутора маргиналов — возможно.


    То есть, Вы оцениваете научные гипотезы количеством последователей? И после этого именно меня считаете мракобесом? Ну, ну :) Вообще-то известно, что хлоропласты в процессе фотосинтеза используют квантовую механику для передачи энергии без потерь. Поэтому гипотеза о том, что и нейроны могут пользоваться квантовой механикой с какой-то целью, представляется вполне разумной.

    Что такое «новое» в Вашем представлении? С чего Вы взяли, что сами способны сгенерировать что-то новое?


    А при чём тут моё представление? Есть вполне конкретное формальное математическое определение: новое — это то, что не выводится из наперёд зафиксированной системы аксиом.

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

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


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

    Ну, и, при всём уважении, задачи у вас (не конкретно у Вас, а у лидеров сообщества любителей глубого обучения) совсем не в том, чтобы сделать нечто универсальное, а в том, чтобы отжать себе побольше финансовых потоков из разнообразных областей экономической деятельности, продав при этом побольше облачного машинного времени :)
  • Рисуем остаток совы на базе нейросетей
    0
    Сотни тысяч нейронов, естественно.
  • Рисуем остаток совы на базе нейросетей
    0
    Ну, если Вы у нас такой уж великий просветитель, расскажите, в чём конкретно заключается мракобесие? Квантовое сознание — вполне себе рабочая гипотеза. Нейронная сеть — простая арифметическая конструкция, следовательно, ничего нового сама по себе она сгенерировать не может. И никаких скрытых магических ролей нейрону я не приписываю. Просто известно, что натуральный нейрон — штука очень сложная. Сеть из сотни живых нейронов может управлять полётом мухи, а искусственные сети сопоставимого размера даже кошечку от белочки отличить не могут :) Так что… В чём мракобесие-то?
  • Рисуем остаток совы на базе нейросетей
    0
    Доказательств довольно много. Например, известно, что нейроны имеют свою внутреннюю память на РНК. Можно, конечно, попытаться это смоделировать, но эти РНК длиной несколько сотен нуклеотидов, и вариантов этих молекул в нейроне тысячи. Ну, попробуйте смоделировать сеть хотя бы из тысячи таких элементов.

    Дело же не в том, что вот прямо таки нам нужен нейрон, а в том, что в реальных нейронах упаковано очень много информации и идёт множество параллельных процессов её считывания и записи. Результат работы нейрона уж точно не сводится к простым дифференцируемым функциям, что применяются в искусственных нейросетях. Сам отдельный нейрон способен самообучаться. Кроме того, есть некоторые основания полагать, что нейроны умеют пользоваться квантовыми вычислениями. И давно и точно известно, они пользуются случайными процессами.

    О искусственных нейронных сетях фантазировать можно очень долго, но факт остаётся фактом — это просто способ аппроксимации функций. Можно возникающую при этом структуру описывать в поэтических терминах, но… зачем самих себя-то обманывать? Искусственная сеть не может выйти за рамки Теоремы Гёделя, а человек может. Вот Вам и водораздел по творческим способностям.
  • Рисуем остаток совы на базе нейросетей
    0

    Я просто реалист.

  • Рисуем остаток совы на базе нейросетей
    0
    Как и все в этом мире. Просто у Вас кусков побольше и обработки посложнее.


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

    Как-то так. Живые нейроны гораздо сложнее, чем нейроны в ИИ, и очень многие молекулярные процессы, происходящие в живых нейронах, являются важными и для интеллекта, и для творчества. Можно ли их смоделировать иначе? Может быть, и можно. Но в современных исскуственных нейросетях такого точно нет. Поэтому, пока всего лишь аппроксимация сложных функций.
  • Российские ученые привлекли нейронную сеть к поиску противораковых лекарств
    0
    Это техника обучения сетей такая. Ну, то есть, там действительно обучение с подкреплением.
  • Российские ученые привлекли нейронную сеть к поиску противораковых лекарств
    0
    Интересно, мне одному кажется странной методика тестирования результатов? Эмс… Они же даже не получили никаких конкретных соединений, только распределение вероятностей, в которые попали какие-то уже известные соединения. Или я чего-то не понимаю?

    AAE was trained on fingerprint, LCONC and GI data for 6252 compounds profiled on MCF-7 cell line. After that we sampled 640 vectors from prior distribution n latent layer with 640 GI values from normal distribution
    N (5,1). Based on this data, we used decoder to generate 640 probability vectors with corresponding LCONC values. Then we extracted the set of probability vectors with LCONC < -5.0 M. In total, we obtained 32 vectors. We screened 32 vectors them against a library of 72 million compounds derived from Pubchem [25] (Figure 2). We sed the maximum likelihood function to select top 10 hits for each of the 32 vectors.


    Если это и правда было исследованием, без кавычек, то это вполне в духе времени. Современная наука продвинулась настолько далеко и глубоко в большинстве сфер знаний, что скоро «рядовым» учёным будет всё сложнее открывать что-то принципиально новое, так как чтобы дойти до конечной грани уже имеющихся исследований нужно потратить очень много времени на обучение, а потом после этого ещё тратить время на более глубокие исследования. Возможно, что в [не]отдалённом будущем учёным только и останется, что работать над тем, чтобы попытаться понять результаты научных достижений, сделанных нейронными сетями.

    Да. Это серьёзная проблема, но, обычно, эта проблема в науке решается выработкой нового языка, который позволяет обобщить имеющиеся результаты и двигаться дальше. Нейронные бы сети пригодились в выработке этого языка, потому что они как раз нацелены на обобщение. Но пытаться получить качественно новые результаты на статистике из прошлого, ну, это, как минимум, весьма странное желание.
  • Российские ученые привлекли нейронную сеть к поиску противораковых лекарств
    –1
    Мда уж. Тут дьявол, однако, в деталях. На какой выборке обучали? На какой выборке проверяли? Какие именно препараты смогла угадать сеть (в том смысле, а насколько отличаются формулы в обучающей выборке от того, на чём тестировали)? Каков проент был угадывания и насколько он отличается просто от случайного? Те «новые» формулы, которые не попали в тестовую выборку, они вообще реальным химическим веществам, которые создать можно, соответствуют?

    Ну и ссылка на подробное описание эксперимента не помашеала бы.

    Как-то это всё… Эмс. Такое ощущение, что настоящая наука и поиск настоящих знаний сейчас активно будет подменяться такими вот «исследованиями». А IT-шники станут специалистами во всех областях знаний сразу. Грустная картинка.
  • Современный подход к сборке мусора
    0
    Так в том-то и дело, что нет безопасных языков в природе почти. Просто… нет. История про Java — описана выше. Вот вам про python.

    То есть сдалать-то безопасный язык можно… а потом добавляются фичи, ещё фичи, примочки, хотелочки… и оп-па: язык у вас, оказывается — небезопасный. Его, оказывается, нужно на уровне операционной системы ограничивать. А тогда, извините, за что мы, собственно, платим?


    Безопасные языки есть. И есть безопасные системы. Я уже приводил пример MirageOS. Unsafe-режимы нужны, в основном, именно для того, чтобы вписываться в существующие native-экосистемы или использовать native-библиотеки, потому что родных нет. Если такой необходимости нет, то можно написать операционку типа House, и жить целиком на Haskell, на одной дискете и не испытывать проблем с производительностью.

    Native — это не технологическая необходимость, а экономическая. Я уже говорил, что да, действительно, это важный фактор. И моя точка зрения заключается в том, что именно он самый важный фактор в устойчивости текущих основанных на Си/Си++ программных экосистем. Просто кода понаписано столько, что его уже не перенести никуда за разумные деньги. Не в скорости тут дело совсем. Уже довольно долго существуют безопасные системы, которые по скорости исполняемого кода уделывают Си/Си++. ATS, например.

    А вот тут — в точку. Программа — это газ. И её сложность — тоже. Вася не сможет реализовать менее эффективную схему управления/ ресурсами на языке без GC. Просто не сможет. Его программа — будет падать и всё.


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

    При этом, программа вполне себе работала два месяца подряд, потом падала, потом снова работала.

    И я сомневаюсь, что это нетипичная ситуация.

    Действительно: а чёб нам не ввести подсистему, которая должна нам всё «улучшить», а потом начать её героически преодолевать? И всё равно GC нет-нет да отжирает свои ресурсы, так как отключить его полностью в Java нельзя.


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

    Борьба идёт именно за безопасность, а не за сборку мусора. Сможете предложить, как делать безопасный код с ручным управлением памятью — сообщество возрадуется. Но, к сожалению, это принципиально невозможно.

    А это уж «кто на что учился», извините. Грамотно написанная программа никакой особой боли не вызывает, не больше чем программа на Java. А неграмотно — тут да. Программа на Java, написанная кривыми руками обеспечит целое пополение «условных индусов» работой на годы вперёд. Подобная же программа на C++ — просто не заработает. Но является ли это недостатоком Java и проблемой C++? Зависит от ваших задач…


    Ещё как заработает! Нет, ну в самом деле. Вон в соседней статье обсуждают косяки в коде MySQL.

    Кстати. Вы сужаете тему принудительно к Java против C++. Java, действительно, не является идеальным языком с точки зрения надёжности, безопасности и технологической продвинутости. Тут бы со Scala надо сравнивать.

    Но есть и другие языки, в которых всё намного лучше. А сама технология безопасных языков и language-level os развивается. Пока в академическом сообществе. Может быть, она там останется навсегда. А, может быть, и не останется. Уж слишком хорошо иногда получается. Снова упомяну ATS и Arrp.
  • Современный подход к сборке мусора
    0
    Да, идея была красивой. Но… не работает. Без аппаратной поддержки — не работает. Вот, собственно, официальная капитуляция.


    А в чём Вы видите факт капитуляции? Ну да, на поддержку Applet-ов забивают постепенно, потому что есть JavaScript. Вполне естественно, об этому говорили ещё тогда, когда V8 только появился.

    Java вообще и сборка мусора в частности — это прекрасная иллюстрация известного принципа: на всякий сложный вопрос имеется ответ – ясный, простой и ошибочный.


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

    Тут же дело какое. Сборка мусора — это не просто способ управления памятью, это, действительно, техника которая влияет на всю систему конкретного языка. Если сборки мусора нет, то библиотеки надо писать одним способом, а если есть, то можно писать другим. И со сборкой мусора библиотеки могут быть гораздо более гибкими. А это тоже важно, если программист может не тратить 50% своего времени на продумывание схемы управления ресурсами, а сразу реализовывать алгоритм.

    На Си++ тоже, наверное, можно сразу сесть за реализацию, ничего не продумывая в плане потока ресурсов. Но лично мой опыт показывает, что потом 10 раз придётся всё переписывать.

    Скорость разработки тоже штука важная. И это было понятно ещё во времена Алгол-68.

    Ну да. А сколько они тратят на обслуживание двух видов виртуальной памяти друг над другом??


    В смысле? В безопасных языках нет виртуальной памяти. На том и стоят. А когда они работают с виртуальной памятью, то продвинутые системы типа .Net или Java пытаются её задействовать в свою пользу. Например, используют cow-отображения страниц при копировании больших объектов. Можно так сделать на Си++? Можно. Но кто же так будет делать? На Си++ скорее всего, человек просто наплодит адову схему из перекрёстных ссылок.

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

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

    Просто потому что проигрывает в скорости другим подходам.


    Нет объективных данных, что проигрывает. Проблема со сборкой мусора не в проигрыше вообще по скорости, а в том, что есть проблема непредсказуемых задержек. В среднем, в пакетных режимах, сборка мусора забирает до 5% времени (в равнении с виртуальной памятью — копейки), в зависимости от задачи.

    Проблема именно с непредсказуемыми задержками. Но опять же. Когда всё живёт поверх виртуальной памяти, то никаких гарантий на задержки тоже нет. TLB будет вносить неопределённости, операционка будет дефрагментацией заниматься, cow-процессы будут происходить.

    Автоматически от использования Си++ проблема не исчезнет. Для гарантии задержек нужно будет специальным образом писать код и специальным образом резервировать ресурсы. Но в точности такое же можно делать и в системах со сборкой мусора. Там есть технологии realtime-пулов памяти и всего такого прочего.

    Гарантированных времён реакции системы можно добится и с одной техникой, и с другой. В конце концов всё упирается в умения и навыки программиста. И это очень важный экономический фактор.

    Ну, а здесь, как ни крути, Си++ Java совсем не конкурент. Даже на Haskell писать проще, чем на Си++. Потому что на Си++ элементарно отстреливаешь себе все конечности, и даже не знаешь, что именно оказывается отстреленным. Отладка больших Си++ программ — вот истинный источник боли и унижения в современном мире.
  • Современный подход к сборке мусора
    0
    Но почему нерациональное? Основной мотивацией порыва SUN в сторону Java была же простое желание: даль сложному софту работать на более простых процессорах. И дело даже не в чайниках, а в том, что они посчитали: их сервра под нагрузкой тратят 30% времени на обслуживание виртуальной памяти. Это без подкачки, просто на управление TLB, создание областей разделяемой памяти, fork-и и прочие такие вещи. У меня где-то статья даже эта завалялась в коллекции. Мотивация у Java — это более рациональное использование ресурсов: зачем проверять каждый доступ в память, если можно гарантировать, что они всегда будут верными?
  • Современный подход к сборке мусора
    0
    Они просто наиболее известны. А так — да, попыток было много.


    Так в том-то и дело, что Lisp-машины не были «попыткой». Это было развитое направление в индустрии. И развивались они быстрее, чем UNIX и Си. И успехов там было много. Люди вот об этом помнят. Поэтому и стремятся повторить успех. Тем более, на новом уровне производительности и технологий можно более интересные вещи делать.

    Ага. И продемонстрировала proof-of-concept с поддержкой scheme и tcl в 1995 году. На календарь давно смотрели?


    И что? Non-profit же. Хотят — делают, хотят — не делают. Guile вообще долго не развивался, но пару лет назад за него снова взялись.

    И да — побочные эффекты часто двигают индустрию вперёд. А вот «философский камень» всё как-то не вырисоывается… Такая «современная алхимия»…


    Да никто там не ищет «философского камня». Просто есть проблемы, есть подходы к их решениям, есть люди, которые верят в эти подходы и работают над ними. Си/Си++ же тоже не идеальны. Да, код быстрый, но работать с динамическими данными тяжело. Если на Java можно написать WebSphere, а на Erlang ту же Riak, то можно ли это сделать на Си++? Ну, не знаю. Никто почему-то не сделал. Почему?

    Чего хорошего в том, что люди пишут 100 парсеров JSON'а и 500 http-серверов? Хорошо хоть TCP/IP стек системный используют.

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


    А люди и так напишут 100 парсеров JSON-а, даже если у них будет один язык программирования. А потом напишут ещё парсеры для других языков программирования. И так далее. Ну, и, люди любят вообще-то искать свою идентичность в каких-нибудь малых группах. Мы вообще не приспособлены ощущать себя хорошо в многомиллионных однообразных коллективах. Поэтому вот так вот.

    Но я не понимаю, а чего Вы так переживаете? Вряд ли экосистема UNIX/Си в ближайшее время куда-нибудь пропадёт. Работы в ней для всех хватит. Маловероятно, что Intel, Apple или Google накроются медным тазом и GCC или LLVM останутся без финансирования и остановятся в развитии.
  • Современный подход к сборке мусора
    0
    А чем Вам так не нравятся Lisp-машины? Исторически, именно на Lisp-машинах было воплощено впервые всё то многообразие идей, с которыми мы сейчас имеем дело. Там были GUI, векторная вёрстка, сетевые протоколы, мультимедия и CAD-ы. Вообще, что было на Lisp-машинах в конце 80-ых на PC появилось только в конце 90-ых, и не в полном объёме. Да что там говорить, даже TCP/IP впервые на Lisp-машине появился. Проблема Lisp-машин даже не в технологиях была, а в том, что Symbolic (основной драйвер Lisp-индустрии) втянулась в какую-то аферу с недвижимостью и прогорела. Но осколки Symbolic живы, и часто являются лидерами в своих направлениях. Например, именно благодаря Lisp-машине NaughtyDog умеет делать огромные бесшовные миры для Uncharted (это к вопросу о производительности; они вообще только из-за давления Sony переписали движок на C++, Lisp их вполне устраивал и по скорости, и по возможностям писать низкоуровневый код).

    И это только экосистема Lisp. А есть ещё экосистема ML. Тоже с довольно интересной историей и своими текущими успехами, в том числе, в высокопроизводительных системах. Вот Вы когда заходите на https://mirage.io/, почему, как Вам кажется, оно тормозит? А вот и нет. Потому что они стартуют виртуальную машину с runtime ML внутри под конкретно Вашу сессию.

    И есть ещё экосистема Haskell. Там тоже интересно.

    Это я всё к чему? К тому, что идея языковой операционной среды жизнеспособна. Тем более, в наше время. Никому не интересно, C++ в приложении поверх Linux, или же Lisp на голом железе, главное, чтобы на JSON и HTTP умел общаться с окружающим миром.

    Ну, то есть, скорее всего, ждёт нас эпоха мультикультурализма в плане языков программирования. Будут экосистемы с разными базовыми языками (тут вот, например, GNU решила Guile Sheme допилить до VM и реализовать поверх неё Python, JS, Ruby и Lua), ну, а программист уже будет просто выбирать в какой экосистеме ему комфортнее.

    Экосистема С/С++ вряд ли куда-то пропадёт с этого праздника жизни и разнообразия, но возвращение Lisp-машин, или появление униядер ML, или мощных runtime-ов Go вполне, мне кажется, имеет смысл приветствовать.

    Повторюсь, людям это интересно, и это не давление сверху со стороны SUN или Microsoft, просто людям так эффективнее работается. Хорошо же.
  • Современный подход к сборке мусора
    0
    Эта идея вечна и постепенно воплотится в жизни. Это интересный challenge и люди не сдадутся. Да, может быть, пока это обратно всё ушло в НИР, но там прогресс довольно существенный.

    Советую вам ради интереса посмотреть на ICFP-2015 и ICFP-2016. Там довольно большая движуха именно на эту тему. Очень много объективно крутых проектов.

    Они пока ещё не вписаны в общую экосистему, но по отдельности впечатляют. Arrp какой-нибудь с глобальной оптимизацией и вращениями вычислений над многомерными массивами, и автоматическим параллелизмом (TensorFlow тихонько завидует в сторонке). Или тот же Ur/Web.

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

    Не очевидно, кстати, что SUN погорела именно из-за Java. У них много косяков в стратегии было.
  • Современный подход к сборке мусора
    +1
    У Эльбруса другая идея. И тоже не особо аппаратно экономная: нужно память тратить на тэги. Если нужна надёжность, то это отлично. Но скорость снижает и сложность архитектуры увеличивает.

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

    Но сейчас всякая такая техника то там, то здесь вылазит. Например: Ur/Web. Штука умеет целиком про клиент-серверное приложение с базами данных доказывать, что оно корректное, вычислять регионы жизни ресурсов и обходится без сборки мусора. Скорость на уровне C++, а кода раз в 10 меньше. Плюс GADT и всё такое прочее. Минус в том, что не для каждой программы она способна построить вывод всего того, что нужно, иногда вывод отрезается по глубине рекурсии. Но автор пишет, что, для обычных программ, а не специальных контрпримеров, всё нормально.
  • Современный подход к сборке мусора
    +1
    Крутые IDE, написанная на Си (я думаю, что нам тут не важно, на Objective или Plus Plus) — это, например, Microsoft Visual Studio, XCode или Open Watcom. ViM и Emacs, конечно, системы с другим подходом к организации проесса написания кода, но я бы не сказал, что они менее эффективны, чем IDE. А почему? А потому что, сюрприз: ViM и Emacs не на Си написаны, на Си написаны только их ядра, а основной функционал прописывается в скриптах (со сборкой мусора), которые дают намного-намного больше возможностей, чем типичная IDE. То есть, как бы, Вы мимо злорадствуете
  • Современный подход к сборке мусора
    0
    Это если объекты большие. А у серверных ребят наоборот всё. У них там куча мелких записей и сложные графы зависимостей между ними. Ну, вот да, стиль программирования такой. То есть, вполне бывает так, что одна запись о ФИО держит в памяти страницу целиком.