Здравствуйте, Sharov, Вы писали:
S>А кастыдей из-за типизации там где не надо понаставит.
Чего???

S>>>А в остальном sql вполне типизированный язык запросов -- объдинить(union) курицы и яйца не получится.
S>>Да как нефиг делать. Вы посмотрите на таблицу implicit преобразований в T-SQL.

S>Я про ansi sql, а не диалекты.
Я за вами не успеваю — только что был T-Sql
Ничего, ANSI ещё хуже.

Здравствуйте, scf, Вы писали:

scf>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Хм. Вообще-то он есть — MAC-адрес. Почти прибит. Но за пределы локалки не передается. Нужно ? Зачем ?
scf>Чтобы после переезда в другую страну включаешь кофеварку, она лезет на сервер. И сервер знает, что а) это та же кофеварка б) она теперь в другой стране. Решает проблему аутентификации и локализации.
На самом деле вместо "адреса" тут нужна вшитая в каждую кастрюлю пара ключей — публичный/приватный.
Ну, как в современных IP-телефонах. Удивительно, как производители в этой отрасли протрахались 15 с абсолютно дырявыми реализациями вроде "делаем запрос по FTP и открытым текстом качаем файлик настроек для аппарата, вместе с именем/паролем пользователя на SIP сервере". Три поколения костылей сменилось, пока они не допетрили использовать SSL и PKI.

Здравствуйте, Sinclair, Вы писали:

S>А если я завтра выпущу свою бесплатную ОС, рассчитанную на бесплатный софт, то в неё тупо не пойдут разработчики, т.к. им за это не платят. А, следовательно, не пойдут и пользователи, потому что там нет софта.

То, что ты говоришь, верно для некоторых ниш: например, open source игр, действительно, меньше, чем платных. В меньшей степени это верно и для приложений с графическим интерфейсом.
Open source разработчики по большей части пишут то, что им самим интересно и нужно. При этом получается софт 'для программистов и админов', что оказалось востребованым на серверах и на рабочих станциях программистов. В результате на серверах open source софт вытеснил коммерческий.

Возвращаясь к теме native vs VM:
Соглашусь, что при большом числе процессорных архитектур распространять программы в промежуточных кодах имеет смысл.
С другой стороны, польза от зоопарка процессорных архитектур неочевидна — это только бы усложнило жизнь программистам, т.к. по сути эти архитектуры мало чем отличались бы.

Здравствуйте, lpd, Вы писали:

lpd>Возвращаясь к теме native vs VM:
lpd>Соглашусь, что при большом числе процессорных архитектур распространять программы в промежуточных кодах имеет смысл.
lpd>С другой стороны, польза от зоопарка процессорных архитектур неочевидна — это только бы усложнило жизнь программистам, т.к. по сути эти архитектуры мало чем отличались бы.

Ну так если подробности архитектуры видны только системным программистам — авторам AOT/JIT генераторов — то что до этого остальным программистам?
А насчёт усложнения есть некоторые сомнения — например, тот же Intel спокойно бы выкинул FPU, который устарел сразу по нескольким параметрам, и стало бы легче чуть менее, чем всем.

Здравствуйте, netch80, Вы писали:

N>Ну так если подробности архитектуры видны только системным программистам — авторам AOT/JIT генераторов — то что до этого остальным программистам?

Если компилировать программы из промежуточного кода в коды процессора сразу после инсталляции, то ты прав. А JIT-компиляция уже не совсем прозрачна, т.к. усложняет процесс запуска программы.

N>А насчёт усложнения есть некоторые сомнения — например, тот же Intel спокойно бы выкинул FPU, который устарел сразу по нескольким параметрам, и стало бы легче чуть менее, чем всем.
Понадобилось бы стандартизировать промежуточный код и его динамическую линковку(если ее оставлять). Хотелось бы, чтобы все это было оправдано существенными улучшениями процессоров, а не просто отключением поддержки legacy-инструкций.
Процессоры, выпускаемые разными фирмами по одной архитектуре(Intel и особенно Arm) и без того отличаются между собой, оставаясь совместимыми. Не исключено, что этого достаточно для развития технологий процессоров.
Это раньше у всех был Windows, и для него shareware программы, которые, действительно, кто-то мог не перекомпилировать под новую архитектуру. Вот это настоящий legacy.
А сейчас:
— офисным пользователями нужен ограниченный круг программ, которые производители пересоберут под новый процессор, да и нет у офисных пользователей потребности в новых процессорах быстрее 3Гц.
— домашним пользователем нужны только браузер и видеокарта с поддержкой видео и 3d графики.
— на серверах у всех Linux и программы из open-source репозиториев, которые быстро пересобираются сообществом.
Получается, проблема несовместимости осталась в 90х когда новые процессоры появлялись чаще.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:
S>>А кастыдей из-за типизации там где не надо понаставит.
S>Чего???

Я имел в виду , что типизация не бесплатна. И привело бы к усложнению ansi sql, которое бы пришлось обплясывать разным вендорам.

S>Я за вами не успеваю — только что был T-Sql
S>Ничего, ANSI ещё хуже.

Я же изначально говорил про sql (ansi) и его диалекты типа t-sql. Для своих задач он вполне годится, и минимальная типизация присутствует.

Здравствуйте, WolfHound, Вы писали:

WH>Ну вот собственно таким микропрограммам никто не мешает быть статически типизированными.
WH>Более того писать их можно не в блокноте, а в полноценной ИДЕ которая если делать правильно будет запускаться за доли секунды.
WH>Sublime запускается мгновенно. Когда нитра станет нативной она тоже будет стартовать доли секунды. Сейчас при старте .НЕТ тормозит.

В теории ты вроде бы прав... Но смотрим на практику (на существующие в данный момент языки и инструменты) и видим, что все подобные задачи решаются исключительно на динамических языка. Может мы что-то не учитываем в наших рассуждениях? )))

WH>>>2)Создание консольного приложения на C# занимает несколько секунд.
_>>Угу, в фантазиях. )
WH>На практике.

Ну давай посмотрим на конкретику. Вот реальный пример из жизни, про который я писал выше. Значит скрипт должен для каждого fb2 файла в текущем каталоге выполнить преобразование его содержимого (преобразовать все html entities в их юникод-представление) и засунуть файл в zip архив с именем name.fb2.zip. Плюс к этому исходный файл должен быть на всякий случай сохранён под именем name.fb2.bak (чтобы программы анализа fb2 файлов его больше не видели). Реализующий всё это Питон скрипт занял у меня ровно 9 строчек лаконичного кода, который я писал порядка 3-ёх минут, из которых одну потратил на поиск в гугле имени функции и модуля из стандартной библиотеки для преобразования html entities. Запуск Notepad++ и потом скрипта естественно мгновенные. А за какое время ты с нуля напишешь на C# аналогичное решение и сколько строчек кода оно будет занимать?

_>>Проблема таких систем (кстати Midori/Singularity далеко не первые в этой области, намного раньше было например такое http://www4.cs.fau.de/Projects/JX/index.html решение), что они очень ультимативные: или всё прикладное ПО написано на соответствующем управляемом языке или система просто не работает (нельзя написать один критичный кусочек на голом ассемблере). Ну и соответственно пока я не увижу реализацию например кодека h.264 на управляемом языке, не уступающую по эффективности классическим нативным реализациям, то в нормальное будущее подобной ОС не поверю.
WH>С этим проблем нет.
WH>Дафна может доказывать любой императивный код включая ассемблер.

Ну в такой вариант я уже могу поверить, но это будет уже весьма далеко от Mirodi и им подобным... Кстати, а где-нибудь можно взглянуть на:
— примеры применения Дафны в каких-то реальных проектах (не важно на каких языках)
— хоть один пример для других языков (пускай и не такую экзотику, как ассемблер)?

Здравствуйте, Sinclair, Вы писали:

_>>Так я как бы вполне одобряю идею распространения байткода (ну естественно не такого как в .net, а скорее такого как llvm, но это не суть). Только вот с фактом и возможностью верификации подобное распространение ПО никак не связано. И вот как раз на счёт возможности такой верификации у меня есть сомнения. Правда так сказать теоретические (сам я как-то ни одного подобного верификатора пока не писал).
S>Не очень понял, в чём именно сомнения. "Такая верификация" вполне себе встроена во вполне себе реально существующие системы.

Есть публичные примеры? )

Здравствуйте, alex_public, Вы писали:

_>В теории ты вроде бы прав... Но смотрим на практику (на существующие в данный момент языки и инструменты) и видим, что все подобные задачи решаются исключительно на динамических языка. Может мы что-то не учитываем в наших рассуждениях? )))
Интерпретатор динамически типизированного языка может написать школота.
Статически типизированный язык с выводом типов может написать далеко не каждый.
И большинство из тех, кто может оторванные от реальности учёные у которых всегда получается хаскель.
А остальным платят большие деньги за другую работу.

_>Ну давай посмотрим на конкретику. Вот реальный пример из жизни, про который я писал выше. Значит скрипт должен для каждого fb2 файла в текущем каталоге выполнить преобразование его содержимого (преобразовать все html entities в их юникод-представление) и засунуть файл в zip архив с именем name.fb2.zip. Плюс к этому исходный файл должен быть на всякий случай сохранён под именем name.fb2.bak (чтобы программы анализа fb2 файлов его больше не видели). Реализующий всё это Питон скрипт занял у меня ровно 9 строчек лаконичного кода, который я писал порядка 3-ёх минут, из которых одну потратил на поиск в гугле имени функции и модуля из стандартной библиотеки для преобразования html entities. Запуск Notepad++ и потом скрипта естественно мгновенные. А за какое время ты с нуля напишешь на C# аналогичное решение и сколько строчек кода оно будет занимать?
Если в C# будут нужные библиотеки всё будет примерно так же.

_>Ну в такой вариант я уже могу поверить, но это будет уже весьма далеко от Mirodi и им подобным... Кстати, а где-нибудь можно взглянуть на:
Mirodi это продолжение работы на тему Singularity и Verve.

Because of their complexity, a holy grail of software verification has been to verify properties of operating systems. Operating systems are usually written in low-level languages, such as C, that provide very few guarantees. The Singularity project took the approach of writing an operating system in C#, a type-safe, memory-safe language. A weakness of this approach is that operating systems necessarily need to call lower-level code to, for instance, move the stack pointer. Verve addresses this problem by partitioning the operating system into verified assembly that is required to be low-level and a trusted interface to rest of the operating system, written in C#. There is a trusted specification that guarantees the low-level assembly code does not mess with the heap and that the high-level C# code does not mess with the stacks.

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

_>- примеры применения Дафны в каких-то реальных проектах (не важно на каких языках)
Не интересовался.
1)Дафна императивный ОО язык. Соответственно натянуть её на любой из популярных языков дело техники.
2)Дафна анализирует каждую функцию независимо от других. А значит анализ можно распараллелить и результат закешировать.
Те не будет проблем даже терабайтом исходников.

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

Здравствуйте, lpd, Вы писали:

N>>Ну так если подробности архитектуры видны только системным программистам — авторам AOT/JIT генераторов — то что до этого остальным программистам?
lpd>Если компилировать программы из промежуточного кода в коды процессора сразу после инсталляции, то ты прав. А JIT-компиляция уже не совсем прозрачна, т.к. усложняет процесс запуска программы.

Ты это усложнение и не заметишь. Поставил продукт в виде бинарников IL, файлов данных и т.п. — а старт бинарника по любому исполняет RTLD. Он и сейчас везде достаточно нетривиальный — чтение ELF/COFF/etc., определение сегментов для загрузки, расчёт перемещений, линковка автоподключаемых SO/DLL — если к этому добавится конверсия прочтённого IL кода в команды местного процессора, это лишь замедлит старт. Прозрачность для автора программы сохранится по полной.

N>>А насчёт усложнения есть некоторые сомнения — например, тот же Intel спокойно бы выкинул FPU, который устарел сразу по нескольким параметрам, и стало бы легче чуть менее, чем всем.
lpd>Понадобилось бы стандартизировать промежуточный код и его динамическую линковку(если ее оставлять). Хотелось бы, чтобы все это было оправдано существенными улучшениями процессоров, а не просто отключением поддержки legacy-инструкций.

Ну примеры Java/.NET/etc. показывают, что преимущество в виде пресловутого "write once, run anywhere" таки есть — а где его нет, проблема почти всегда не в процессоре. Исключения идут на случаи типа "мы тут ничего векторного не можем завести => FPS <= 10".

lpd>Процессоры, выпускаемые разными фирмами по одной архитектуре(Intel и особенно Arm) и без того отличаются между собой, оставаясь совместимыми. Не исключено, что этого достаточно для развития технологий процессоров.
lpd>Это раньше у всех был Windows, и для него shareware программы, которые, действительно, кто-то мог не перекомпилировать под новую архитектуру. Вот это настоящий legacy.
lpd>А сейчас:
lpd>- офисным пользователями нужен ограниченный круг программ, которые производители пересоберут под новый процессор, да и нет у офисных пользователей потребности в новых процессорах быстрее 3Гц.

Даже есть так, офисные это далеко не все, и необязательно самый денежный сегмент.

lpd>- домашним пользователем нужны только браузер и видеокарта с поддержкой видео и 3d графики.

И производителям игр вечно не хватает скорости.

lpd>- на серверах у всех Linux и программы из open-source репозиториев, которые быстро пересобираются сообществом.

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

lpd>Получается, проблема несовместимости осталась в 90х когда новые процессоры появлялись чаще.

Да, частично она решена. Но далеко не полностью.

Здравствуйте, WolfHound, Вы писали:

_>>В теории ты вроде бы прав... Но смотрим на практику (на существующие в данный момент языки и инструменты) и видим, что все подобные задачи решаются исключительно на динамических языка. Может мы что-то не учитываем в наших рассуждениях? )))
WH>Интерпретатор динамически типизированного языка может написать школота.
WH>Статически типизированный язык с выводом типов может написать далеко не каждый.
WH>И большинство из тех, кто может оторванные от реальности учёные у которых всегда получается хаскель.
WH>А остальным платят большие деньги за другую работу.

Т.е. ты хочешь сказать, что просто пока никто не осилил сделать правильный статически типизированный язык, подходящий под скриптовой стиль использования? )

_>>Ну давай посмотрим на конкретику. Вот реальный пример из жизни, про который я писал выше. Значит скрипт должен для каждого fb2 файла в текущем каталоге выполнить преобразование его содержимого (преобразовать все html entities в их юникод-представление) и засунуть файл в zip архив с именем name.fb2.zip. Плюс к этому исходный файл должен быть на всякий случай сохранён под именем name.fb2.bak (чтобы программы анализа fb2 файлов его больше не видели). Реализующий всё это Питон скрипт занял у меня ровно 9 строчек лаконичного кода, который я писал порядка 3-ёх минут, из которых одну потратил на поиск в гугле имени функции и модуля из стандартной библиотеки для преобразования html entities. Запуск Notepad++ и потом скрипта естественно мгновенные. А за какое время ты с нуля напишешь на C# аналогичное решение и сколько строчек кода оно будет занимать?
WH>Если в C# будут нужные библиотеки всё будет примерно так же.

Все библиотечки имеются (во всяком случае судя по документации): https://msdn.microsoft.com/ru-ru/library/7c5fyk1k(v=vs.110).aspx и https://msdn.microsoft.com/ru-ru/library/system.io.compression.zipfile(v=vs.110).aspx. Но при этом я всё равно крайне сомневаюсь в 9-и строчка и 2-ух минутах на C#.

_>>Ну в такой вариант я уже могу поверить, но это будет уже весьма далеко от Mirodi и им подобным... Кстати, а где-нибудь можно взглянуть на:
WH>Mirodi это продолжение работы на тему Singularity и Verve.
WH>В данном подходе ничто не запрещает иметь пользовательский верифицированный ассемблерный код.

Я в курсе. Но Mirodi и Singularity — это опять же не реальные проекты. В том смысле что не используемые где-то в реальной работе.

WH>Более того я сомневаюсь, что он вообще нужен при наличии halide.

Ну SIMD — это не единственное применение низкоуровневого кода. К примеру написание какой-нибудь VM на языке типа Java или safe C# кажется крайне сомнительным.

_>>- примеры применения Дафны в каких-то реальных проектах (не важно на каких языках)
WH>Не интересовался.
WH>1)Дафна императивный ОО язык. Соответственно натянуть её на любой из популярных языков дело техники.
WH>2)Дафна анализирует каждую функцию независимо от других. А значит анализ можно распараллелить и результат закешировать.
WH>Те не будет проблем даже терабайтом исходников.
_>>- хоть один пример для других языков (пускай и не такую экзотику, как ассемблер)?
WH>А какая разница что доказывать императивный код, который меняет локальные переменные или ассемблерный код, который меняет регистры?

Меня вот интересуют конкретные реальные примеры использования. Я практик, а не теоретик. )

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, lpd, Вы писали:

N>>>Ну так если подробности архитектуры видны только системным программистам — авторам AOT/JIT генераторов — то что до этого остальным программистам?
lpd>>Если компилировать программы из промежуточного кода в коды процессора сразу после инсталляции, то ты прав. А JIT-компиляция уже не совсем прозрачна, т.к. усложняет процесс запуска программы.

N>Ты это усложнение и не заметишь. Поставил продукт в виде бинарников IL, файлов данных и т.п. — а старт бинарника по любому исполняет RTLD.
Мне больше всего не нравится отладка при JIT-компиляции. В нативном коде есть только исходник и бинарный код, причем второе легко сопоставить с первым. При JIT-компиляции добавляется промежуточный код, и уже не так просто понять что к чему без помощи VM, просто посмотрев и дизассемблировав память процесса.
Вроде как Linux потому и нравится программистам, что его можно разобрать на составляющие и отладить или заменить их. Промежуточный код же отдаляет низкоуровневые операции от пользователя. Хотя при написании высокоуровневых программ разница не столь значительна.

lpd>>Получается, проблема несовместимости осталась в 90х когда новые процессоры появлялись чаще.

N>Да, частично она решена. Но далеко не полностью.
Процессоры достигли хорошего уровня(если не максимума), и дальнейшее увеличение скорости нужно только на серверах, для процесса разработки(инженеров и дизайнеров) и для игр + для javascript. Причем игры все равно оптимизируют векторными инструкциями. Получается, промежуточный код решает только нишевые проблемы (софт для дизайнеров/проектировщиков).
Я же рассматриваю вопрос с позиций Linux, и для open source промежуточный код нужен как машине пятое колесо, решающее достаточно гипотетические проблемы процессоростроителей. Вот с компиляцией промежуточного кода в бинарный в момент установки приложения я бы не спорил, если бы разнообразие процессоров привело к необходимости распространения программ таким способом.

Здравствуйте, alex_public, Вы писали:

_>Т.е. ты хочешь сказать, что просто пока никто не осилил сделать правильный статически типизированный язык, подходящий под скриптовой стиль использования? )
Может и сделал. Но его ещё и распространить нужно.
Ну и любителей писать скрипты на хаскеле тоже забывать не стоит.
http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html

_>Все библиотечки имеются (во всяком случае судя по документации): https://msdn.microsoft.com/ru-ru/library/7c5fyk1k(v=vs.110).aspx и https://msdn.microsoft.com/ru-ru/library/system.io.compression.zipfile(v=vs.110).aspx. Но при этом я всё равно крайне сомневаюсь в 9-и строчка и 2-ух минутах на C#.
А ты можешь показать код на питоне?
Чтобы понять, что конкретно он делает.

_>Я в курсе. Но Mirodi и Singularity — это опять же не реальные проекты. В том смысле что не используемые где-то в реальной работе.
1)Ты сказал, что этот подход далёк от мидори. Я тебе показал, что это нет так.
2)Joe Duffy говорит, что мидори убили по политическим причинам. И если бы проект был опенсорс, то всё было бы несколько иначе.
Похоже он бросил микрософт и начал заниматься чем-то другим.
http://joeduffyblog.com/2017/06/01/an-update-on-me-pulumi/
Судя по этой фразе дело мидори продолжается.

Since then, I’ve been having the time of my life spelunking at the intersection of distributed cloud systems, programming languages, and machine intelligence.

WH>>Более того я сомневаюсь, что он вообще нужен при наличии halide.
_>Ну SIMD — это не единственное применение низкоуровневого кода. К примеру написание какой-нибудь VM на языке типа Java или safe C# кажется крайне сомнительным.
1)Тут разговор про язык, намного более совершенный чем Java или safe C#.
2)Всё что тебе нужно это генерировать верифицируемый ассемблер. И ОС его радостно запустит.

Здравствуйте, lpd, Вы писали:

lpd>Мне больше всего не нравится отладка при JIT-компиляции. В нативном коде есть только исходник и бинарный код, причем второе легко сопоставить с первым. При JIT-компиляции добавляется промежуточный код, и уже не так просто понять что к чему без помощи VM, просто посмотрев и дизассемблировав память процесса.
Зачем такие сложности?

lpd>Вроде как Linux потому и нравится программистам, что его можно разобрать на составляющие и отладить или заменить их. Промежуточный код же отдаляет низкоуровневые операции от пользователя. Хотя при написании высокоуровневых программ разница не столь значительна.
Ещё раз. Все компиляторы имеют внутри себя промежуточный код. Просто тебе его не показывают.

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

Здравствуйте, WolfHound, Вы писали:

WH>А разнообразию процессоров мешает только отсутствие софта под новые архитектуры.

Осталось только пояснить, зачем нужны отличающиеся на +-10% скорости, однако несовместимые процессоры, либо доказать значительное отставание Intel/Arm от теоретически возможных процессоров. Выпиливание legacy-инструкций из Intel, о котором говорил netch80, не выглядит достаточной причиной для добавления промежуточного кода. Я, конечно, понимаю, что монополизм затрудняет технический прогресс, однако хотелось бы посмотреть хотя бы на прототип нового супер-процессора, прежде чем менять инфраструктуру инсталляции приложений на миллиарде компьютеров.

Здравствуйте, lpd, Вы писали:

lpd>Осталось только пояснить, зачем нужны отличающиеся на +-10% скорости, однако несовместимые процессоры,
Чего тебя вообще так это волнует?
Система команд процессора будет заботить только производителя процессора. И больше никого.

lpd>либо доказать значительное отставание Intel/Arm от теоретически возможных процессоров.
А мы не знаем. Дело в том, что разработка процессора дело не дешёвое.
А если его нельзя выпустить на массовый рынок, то он не окупится.
А без софта его на массовый рынок не выпустить.
А если весь софт прибит гвоздями к одной архитектуре...

И нет. Опенсорса не достаточно. Он вообще является микроскопической частью всего софта.

lpd>Выпиливание legacy-инструкций из Intel, о котором говорил netch80, не выглядит достаточной причиной для добавления промежуточного кода.
Есть много других причин.
1)Надёжность и безопасность софта. Верифицируемый код хакать намного сложнее.
2)Удобство разработчиков. Если иметь промежуточный код то не нужно думать о том что там за процессор.
Не нужно собирать кучу версий софта.
Пользователю не нужно думать какой из инсталляторов скачать.
3)Более быстрые и отзывчивые программы. Когда нам не нужно бояться многопоточности, ибо компилятор проверяет что там всё хорошо можно очень агрессивно всё распараллеливать.
4)Значительное упрощение программ. С++ это ад. И это при том что я очень хорошо знаю С++. Но кроме него я знаю ещё много чего. И поэтому могу сравнивать.
5)Выпуск новых версий ВМ с новым оптимизатором ускорит все программы. А не только те которые разработчики не поленились перекомпилировать.
6)Возможность создавать пару процессор и хитровывернутый оптимизатор под него. Какой прирост производительности это даст трудно сказать. Может быть и в разы.

lpd>Я, конечно, понимаю, что монополизм затрудняет технический прогресс, однако хотелось бы посмотреть хотя бы на прототип нового супер-процессора, прежде чем менять инфраструктуру инсталляции приложений на миллиарде компьютеров.
Мы тут рассматриваем ситуацию "весь софт исчез". Нужно писать с чистого листа.

Здравствуйте, WolfHound, Вы писали:

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

lpd>>Выпиливание legacy-инструкций из Intel, о котором говорил netch80, не выглядит достаточной причиной для добавления промежуточного кода.
WH>Есть много других причин.
WH>1)Надёжность и безопасность софта. Верифицируемый код хакать намного сложнее.
WH>2)Удобство разработчиков. Если иметь промежуточный код то не нужно думать о том что там за процессор.
WH>Не нужно собирать кучу версий софта.
WH>Пользователю не нужно думать какой из инсталляторов скачать.
WH>3)Более быстрые и отзывчивые программы. Когда нам не нужно бояться многопоточности, ибо компилятор проверяет что там всё хорошо можно очень агрессивно всё распараллеливать.
WH>4)Значительное упрощение программ. С++ это ад. И это при том что я очень хорошо знаю С++. Но кроме него я знаю ещё много чего. И поэтому могу сравнивать.
WH>5)Выпуск новых версий ВМ с новым оптимизатором ускорит все программы. А не только те которые разработчики не поленились перекомпилировать.
WH>6)Возможность создавать пару процессор и хитровывернутый оптимизатор под него. Какой прирост производительности это даст трудно сказать. Может быть и в разы.
Пункты 1,3 и 4 довольно теоретичны, и ничего не мешает их воплотить жизнь сейчас на этапе сборки софта(в clang), поэтому они нерелевантны.
Остальное имеет смысл, только ты преувеличиваешь роль нового процессора и оптимизации под процессор в конечном user-experience пользователя, который и имеет решающее значение. А между тем все это потребовало бы еще стандартизации промежуточного кода. Кроме того, анализировать присланный пользователем core-dump было бы сложнее.
Получается, если посмотреть теоретически на этот вопрос, то это выглядит красиво. На практике миры софта и процессоров устроены так, что при значительном количестве усилий пользы было бы немного: не грузился бы компьютер в разы быстрее, не отзывчевее были бы приложения, не быстрее бы грузились страницы в браузере, а игры бы оптимизировали все равно вручную. Могу представить заметный выигрыш только в приложениях обработки видео.
Вот в 1990-е и 2000-ные когда каждый год частота процессора увеличивалась на 50%, это бы выглядело полезно.

lpd>>Я, конечно, понимаю, что монополизм затрудняет технический прогресс, однако хотелось бы посмотреть хотя бы на прототип нового супер-процессора, прежде чем менять инфраструктуру инсталляции приложений на миллиарде компьютеров.
WH>Мы тут рассматриваем ситуацию "весь софт исчез". Нужно писать с чистого листа.
В принципе, поезд не ушел, и систему установки/компиляции распространять можно и сейчас — вопрос в спросе.
Хотите — делайте Linux с поддержкой любых процессоров и оптимизацией при инсталляции. Только у современных ОС есть недостатки и серьезнее.

Здравствуйте, lpd, Вы писали:

WH>>И нет. Опенсорса не достаточно. Он вообще является микроскопической частью всего софта.
lpd>Слышу слова прожженного виндузятника. Переубеждать не буду, т.к. это обычно бесполезно.
Просто по тому что я знаю сколько софта делается за пределами опенсорс мирка.
Например, то что я сейчас делаю не опенсорс. И оно никогда не будет опенсорс. Просто по тому что оно заказчику не нужно.
И такого софта на порядки больше чем опенсорса.
Он просто для линуксойдов невидим.

lpd>Пункты 1,3 и 4 довольно теоретичны, и ничего не мешает их воплотить жизнь сейчас на этапе сборки софта(в clang), поэтому они нерелевантны.
clang это С++. А С++ идёт лесом от слова совсем.

lpd>Остальное имеет смысл, только ты преувеличиваешь роль нового процессора и оптимизации под процессор в конечном user-experience пользователя, который и имеет решающее значение.
Юзеры разные бывают.

lpd>А между тем все это потребовало бы еще стандартизации промежуточного кода.
Ты так говоришь, как будто это что-то сложное.

lpd>Кроме того, анализировать присланный пользователем core-dump было бы сложнее.
Наоборот проще. Ибо разбитой памяти не будет. Гонок не будет.
Будет абсолютно предсказуемое завершение процесса.
После которого можно сохранить дамп данных процесса в платформонезависимом формате. Обрати внимание дамп данных, а не сырой памяти.
Ты пойми простую вещь: Архитектура процессора вообще нигде отсвечивать не будет. С ней соприкасаться будут только разработчики процессора. Ну и те, кому просто интересно с этим поиграть.

lpd>Получается, если посмотреть теоретически на этот вопрос, то это выглядит красиво. На практике миры софта и процессоров устроены так, что при значительном количестве усилий пользы было бы немного:
Ох. Усилий в этом случае нужно намного меньше чем сейчас. Причём вообще всем.

lpd>Хотите — делайте Linux с поддержкой любых процессоров и оптимизацией при инсталляции. Только у современных ОС есть недостатки и серьезнее.
Ага. Они все на С написаны.
А нужно делать что-то вроде мидори.
И писать на верифицируемом языке.
Проблема в текущий момент в том, что под эту систему нет софта. Без софта эта система никому не нужна. А под не нужную систему никто не будет писать софт.

Здравствуйте, WolfHound, Вы писали:

_>>Т.е. ты хочешь сказать, что просто пока никто не осилил сделать правильный статически типизированный язык, подходящий под скриптовой стиль использования? )
WH>Может и сделал. Но его ещё и распространить нужно.

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

WH>Ну и любителей писать скрипты на хаскеле тоже забывать не стоит.
WH>http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html

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

_>>Все библиотечки имеются (во всяком случае судя по документации): https://msdn.microsoft.com/ru-ru/library/7c5fyk1k(v=vs.110).aspx и https://msdn.microsoft.com/ru-ru/library/system.io.compression.zipfile(v=vs.110).aspx. Но при этом я всё равно крайне сомневаюсь в 9-и строчка и 2-ух минутах на C#.
WH>А ты можешь показать код на питоне?
WH>Чтобы понять, что конкретно он делает.

Да вроде очевидно объяснил же. Хотя и с кодом проблем нет:

import os, HTMLParser, zipfile

for name in os.listdir('.'):
    if name.endswith('.fb2'):
        data=open(name).read().decode('UTF-8')
        data=HTMLParser.HTMLParser().unescape(data)
        zipfile.ZipFile(name+'.zip', 'w', zipfile.ZIP_DEFLATED).writestr(name, data.encode('UTF-8'))
        os.rename(name, name+'.bak')

Кстати, я что-то обсчитался тогда: по факту оказалось 7 строк всего (и то из-за моего логического разбиения для удобства понимания — так то первые три строки внутри if по сути являются одной строкой).

_>>Я в курсе. Но Mirodi и Singularity — это опять же не реальные проекты. В том смысле что не используемые где-то в реальной работе.
WH>1)Ты сказал, что этот подход далёк от мидори. Я тебе показал, что это нет так.
WH>2)Joe Duffy говорит, что мидори убили по политическим причинам. И если бы проект был опенсорс, то всё было бы несколько иначе.
WH>Похоже он бросил микрософт и начал заниматься чем-то другим.
WH>http://joeduffyblog.com/2017/06/01/an-update-on-me-pulumi/
WH>Судя по этой фразе дело мидори продолжается.
WH>

WH>Since then, I’ve been having the time of my life spelunking at the intersection of distributed cloud systems, programming languages, and machine intelligence.

Хы, товарищ наконец то созрел для организации своего стартапчика... Это позитивно, хотя офис у них конечно весёлый сейчас (http://pulumi.com/contact). Однако не пойму откуда ты взял, что это будет продолжением дела Midori. Я например после прочтения этого его сообщения и изучения их сайта по прежнему не имею ни малейшего представления об их идеях. Облака, ИИ и т.п. — это всё просто текущие относительно хайповые темы...

WH>>>Более того я сомневаюсь, что он вообще нужен при наличии halide.
_>>Ну SIMD — это не единственное применение низкоуровневого кода. К примеру написание какой-нибудь VM на языке типа Java или safe C# кажется крайне сомнительным.
WH>1)Тут разговор про язык, намного более совершенный чем Java или safe C#.
WH>2)Всё что тебе нужно это генерировать верифицируемый ассемблер. И ОС его радостно запустит.

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

Здравствуйте, alex_public, Вы писали:

_>С Хаскелем двойственная ситуация. С одной стороны он весьма лаконичный (частенько даже лучше Питона), а с другой стоит хоть немного выйти за рамки парадигмы ФП (например банально захотеть мутабельную переменную), как начинается такой ад, в сравнение с которым PHP и VB начинают казаться замечательными языками. )))
Зачем тебе изменяемая переменная в скрипте, написанном на хаскеле?
Изменяемые переменные нужны только для оптимизации.

_>Да вроде очевидно объяснил же. Хотя и с кодом проблем нет:

foreach (var name in Directory.EnumerateFiles(".", "*.fb2"))
{
  var data = File.ReadAllText(name, Encoding.UTF8);
  data = HttpUtility.HtmlDecode(data);
  using (var zip = ZipFile.Open(name + ".zip", ZipArchiveMode.Create))
  using (var file = zip.CreateEntry(name).Open())
  using (var writer = new StreamWriter(file, Encoding.UTF8))
    writer.Write(data);
  File.Move(name, name + ".bak");
}

_>Хы, товарищ наконец то созрел для организации своего стартапчика... Это позитивно, хотя офис у них конечно весёлый сейчас (http://pulumi.com/contact). Однако не пойму откуда ты взял, что это будет продолжением дела Midori. Я например после прочтения этого его сообщения и изучения их сайта по прежнему не имею ни малейшего представления об их идеях. Облака, ИИ и т.п. — это всё просто текущие относительно хайповые темы...
Он в своих статьях говорил, что мидори может работать на кластере. Те ОС живёт не на одной машине, а сразу на нескольких.

_>Опять же: в теории — конечно, а на практике — не видел пока ничего подобного. ) И да, я понимаю, что в данной темке обсуждается "альтернативная история", а не реальность. Но это тоже можно обсуждать по разному. К примеру есть определённые решения, эффективность которых уже проверена прямо сейчас и они пока не "захватили мир" только в силу различных "политических" и экономических причин. А вот твои предложения чаще всего имеют ещё и не проверенную на практике эффективность. При этом они мне чаще всего тоже нравятся, но я всегда хочу реальных примеров...
Почти все мои предложения как раз имеют прототипы в виде работающего кода.
Только описанное мной управление памятью не проверено на практике.