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

E>>Ну какие-то задачи удаётся автоматизировать. Но сильно не все.
AVK>И какой из этого вывод?

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

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

E>> Можно, например, написать интерпретатор С++, который проверяет корректность всех указателей и т. п.

AVK>Нельзя, семантика С++ не позволяет. Чтобы позволяла нужен safe код.

Можно, можно. Он и будет safe в таком интерпретаторе.

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

E>Если ты хочешь понять, что я имел в виду, то я пояснил очень подробно.

Не знаю я, что ты там подробно объяснил, но я таки не смог понять, как твоя фраза поясняет, как можно прикладному программисту использовать FPGA без промежуточных слоев абстракций. На всякий случай — FPGA отстоит от С++ по уровню абстракций очень намного дальше, нежели C# от куды. Внутри даже довольно высокоуровневых ксайлинксов там набор универсальных логических блоков с программируемой таблицей истинности, набор универсальных гейтов, завязанных на ноги микросхемы, и программируемая матрица межсоединений. И фсе.

E>А если ты хочешь спорить -- то спорь по существу, а не с примерами и объяснениями...

Я? С тобой? Ты ничего не перепутал? Это ты мне в этой ветке вопрсы начал задавать.

E>На "КУДЕ" есть очень даже прикольные проги.

Да ради бога, я ж не против. Я против того, чтобы писать продакшн софт под эту куду прямо в родных кудовых кодах.

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

M>Можно, можно. Он и будет safe в таком интерпретаторе.

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

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

E>>>Ну какие-то задачи удаётся автоматизировать. Но сильно не все.
AVK>>И какой из этого вывод?

E>Вывод такой, что опыт популярности С/С++ учит нас тому, что "дырявость" абстракций сильно востребованна

Ошибка в логике. "А одновременно с Б" не означает "из А следует Б".

E>, именно из-за того, что проще приспосабливаться к аппаратуре и получить лучшие результаты за меньшие деньги...

За меньшие деньги это точно не про С++.

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

C>>Фортран — он самый неабстрактный язык, который только можно придумать
AVK>Да? А как нибудь обосновать?
А ты на нём писал?

C>> Оптимизатору там простор из-за того, что сам язык очень ограничен, и ты вынужден строить программ из оптимизаторно-дружественных примитивов.
AVK>Это и есть высокая степень абстракции.
Нет. Это высокая степень ограниченности. Скажем, в Фортране-77 запрещена рекурсия, невозможен алиасинг, массивы переменной длины и т.п. Так что оптимизатору из-за этого очень просто работать.

Из "высокой степенни абстракции" там только встроенные настоящие многомерные массивы.

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

M>>Можно, можно. Он и будет safe в таком интерпретаторе.

AVK>Safe он будет, только если зарезать мегафичи навроде реинтерпретации памяти или голых указателей.

Отнюдь. Это его верифицировать нельзя будет, если использовать касты. А в интерпретаторе на каждое слово в "памяти" можно держать свой дескриптор, и все unsafe операции проверять на валидность в рантайме.

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

E>>Если ты хочешь понять, что я имел в виду, то я пояснил очень подробно.

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

Так не в наличии промежуточных уровней абстракции дело, а в невозможности их перепрыгнуть, в отсутствии в них "дырок".
Если у тебя есть JVM — то ты её перепрыгнуть не можешь. Если есть .NET — то можешь, написав unsafe код.
Если у тебя есть FPGA — не надо писать программы в терминах вентилей, надо только из программы иметь возможность перенастроить эти вентили.
Да, это будет делать промежуточный слой абстракции. Но написанный (или модифицированный) специально под твою программу — будет предоставлять все возможности необходимые твоей программе. И фсё.

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

AVK>>Да? А как нибудь обосновать?
C>А ты на нём писал?

Приходилось.

AVK>>Это и есть высокая степень абстракции.
C>Нет. Это высокая степень ограниченности.

Это связанные понятия. Ограничения сами по себе бессмысленны. А вот если они вкупе с абстракциями, тогда и получается самое оно.

C> Скажем, в Фортране-77 запрещена рекурсия, невозможен алиасинг, массивы переменной длины и т.п. Так что оптимизатору из-за этого очень просто работать.

При этом, заметь, самому компилятору никто не мешает использовать в генерируемом коде эти вещи.

C>Из "высокой степенни абстракции" там только встроенные настоящие многомерные массивы.

http://en.wikipedia.org/wiki/Abstraction

Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose.

http://en.wikipedia.org/wiki/Abstraction_(computer_science)

In computer science, abstraction is a mechanism and practice to reduce and factor out details so that one can focus on a few concepts at a time.

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

M>Отнюдь. Это его верифицировать нельзя будет, если использовать касты

safe это оно и есть.

M>. А в интерпретаторе на каждое слово в "памяти" можно держать свой дескриптор, и все unsafe операции проверять на валидность в рантайме.

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

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

M>Так не в наличии промежуточных уровней абстракции дело, а в невозможности их перепрыгнуть, в отсутствии в них "дырок".

То есть в асбтракции самой по себе уже ничего плохого нет? Уже хорошо. Ну а вместо наличия дырок нормальные люди делают абстракции расширяемыми. Начиная с примитивных решений навроде intrinsic функция и заканчивая теми же макросами Немерле или механикой linq в шарпе.

M>Если у тебя есть JVM — то ты её перепрыгнуть не можешь.

Могу. Воспользовавшись JNI.

M>Если у тебя есть FPGA — не надо писать программы в терминах вентилей, надо только из программы иметь возможность перенастроить эти вентили.

Нет, нужна возможность добавить в компилятор FPGA возможность расширения. Прямое управление через все слои абстракции это бееее.

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

AVK>Не знаю я, что ты там подробно объяснил, но я таки не смог понять,
Ну не смог и не смог, бывает.

AVK>как твоя фраза поясняет, как можно прикладному программисту использовать FPGA без промежуточных слоев абстракций. На всякий случай — FPGA отстоит от С++ по уровню абстракций очень намного дальше, нежели C# от куды. Внутри даже довольно высокоуровневых ксайлинксов там набор универсальных логических блоков с программируемой таблицей истинности, набор универсальных гейтов, завязанных на ноги микросхемы, и программируемая матрица межсоединений. И фсе.

И что? У тебя должен быть какой-то инструмент разработки под FPGA. Так вот, я сильно предполагаю, что если этот инструмент будет "дырявым" и позволит завинтить код так, чтобы учесть особенности конкртеного FPGA, то в целом получится лучше...

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

E>>На "КУДЕ" есть очень даже прикольные проги.
AVK>Да ради бога, я ж не против. Я против того, чтобы писать продакшн софт под эту куду прямо в родных кудовых кодах.

Не совсем понимаю, что ты имеешь в виду. Например, если ты пишешь какой-то числодробительный алгоритм, и явно используешь особенности архитектуры конкретной карточки. Например, различаешь доступ через память текстур и доступ через обычный канал -- это "в КУДОвых кодах" или нет?

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

AVK>Только все равно нет никакой гарантии, что при любом, сколь угодно большом количестве прогонов без проблем втоя программа доказанно корректна.

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

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

E>>Вывод такой, что опыт популярности С/С++ учит нас тому, что "дырявость" абстракций сильно востребованна
AVK>Ошибка в логике. "А одновременно с Б" не означает "из А следует Б".
Это у тебя ошибка в логике. Я считаю, что нас учит именно опыт, а не факт какой-то там одновременности. "Дырявость" С++ явно востребованна. Вот есть Ада, например, где с дырявостью осознанно поборолись. И что и где? Неудобно получается

E>>, именно из-за того, что проще приспосабливаться к аппаратуре и получить лучшие результаты за меньшие деньги...
AVK>За меньшие деньги это точно не про С++.

За меньшие деньги за аппаратуру, так скажем...

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

E>И что? У тебя должен быть какой-то инструмент разработки под FPGA. Так вот, я сильно предполагаю, что если этот инструмент будет "дырявым" и позволит завинтить код так, чтобы учесть особенности конкртеного FPGA, то в целом получится лучше...

И на чем основаны такие предположения?

AVK>>Да ради бога, я ж не против. Я против того, чтобы писать продакшн софт под эту куду прямо в родных кудовых кодах.

E>Не совсем понимаю, что ты имеешь в виду.

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

E> Например, если ты пишешь какой-то числодробительный алгоритм, и явно используешь особенности архитектуры конкретной карточки. Например, различаешь доступ через память текстур и доступ через обычный канал -- это "в КУДОвых кодах" или нет?

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

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

AVK>>Только все равно нет никакой гарантии, что при любом, сколь угодно большом количестве прогонов без проблем втоя программа доказанно корректна.

E>Так цель-то не в этом...

А в чем?

E>Кроме того указатели могут быть устроены как-то так, что память вообще фиг испортишь.

Вот это "как то так" и приведет в итоге к статически верифицируемому коду.

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

E>>>Вывод такой, что опыт популярности С/С++ учит нас тому, что "дырявость" абстракций сильно востребованна
AVK>>Ошибка в логике. "А одновременно с Б" не означает "из А следует Б".
E>Это у тебя ошибка в логике.

Ясно, вопросов больше не имею.

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

AVK>И на чем основаны такие предположения?
Наа опыте использования очень дырявых абстракций и не очень

AVK>Я имею в виду, что если использование мегатехнологии Х не будет завернуто в удобные абстракции, рыночного успеха у нее скорее всего не будет.
Аргументы? В том числе и на примере С/С++ vs Ада

AVK>В них. Поэтому, скажем, для шейдеров придуман универсальных язык.
Ну, наверное, по этой пирчине дайректиксовые вычислительные шейдеры сливают "куде" по производительности

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

AVK>Вот это "как то так" и приведет в итоге к статически верифицируемому коду.

Дык о том-то и речь, что С++ спроектирова так, что нифига не изолирует тебя от аппаратуры. Абастракция-то дырявая!

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

AVK>Ясно, вопросов больше не имею.
То, что ты разрешил наконец свои вопросы -- это, IMHO, хорошо. А вот то, что ты пропустил информативную часть моего сообщения -- не очень
Ну да если тебе наконец стало понятно, то и ладно