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

BZ>бог с ним, синтаксисом. шаблоны, если под ними понимается полиморфный код, и в ml есть. raii делается на bracket. с gc — подробности реализации


Ну так Си и С++ одно и тоже

BZ>т.е. у меня такое ощущение что ничего лучше ml чуваки не придумали. где я неправ?

Тут еще не понятно, очень мало пока информации, но из того что уже есть понятно что это все-таки не ml, похоже даже немерле
больший ml чем rust.

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

BZ>бред полнейший. просто в 80-е ява ввела моду на использование байт-кода. никаких принципиальных изменений он не даёт,
А вот тут ты сильно не прав.
Компиляция в байткод имеет убойные преимущества:
1)Валидация кода на клиенте. Те я могу скачать какой угодно код и проверить его на вшивость простым алгоритмом. С нативным кодом такое не получится.
Если сюда добавить еще и грамотный дизайн стандартной библиотеки то вирусы умрут все и сразу.

2)Переносимость между разными процессорами. В том числе теми которые еще не существовали на момент компиляции программы.

3)Генерация кода во время исполнения. Опять без байткода настолько сложно что с этим никто связываться не решается. А если вспомнить про преносимость то совсем тушите свет.

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

BZ>>бред полнейший. просто в 80-е ява ввела моду на использование байт-кода. никаких принципиальных изменений он не даёт,
WH>А вот тут ты сильно не прав.

а ты читаешь то, на что отвечаешь?

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

BZ>>>бред полнейший. просто в 80-е ява ввела моду на использование байт-кода. никаких принципиальных изменений он не даёт,
WH>>А вот тут ты сильно не прав.
BZ>а ты читаешь то, на что отвечаешь?
А ты читаешь то что пишешь?
Ты сказал что байткод ничего не дает. Я тебе аргументированно объяснил где ты не прав.

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

WH>Ты сказал что байткод ничего не дает. Я тебе аргументированно объяснил где ты не прав.

прочти всё же письмо целиком

VD>Если посмотреть на то что есть общее у Ржавчины и Гоги, то это:
VD>1. Типобезопасность (т.е. не гораздо более чем, а просто типобезопасным).
VD>2. ~LL(1) синтаксис (т.е. простота парсинга).
VD>3. Нэйтивность (т.е. компилируемость в исполняемый код).
VD>4. Модульность.
VD>5. Фичи многопоточного программирования (новый трэнд ).
VD>6. Статическая типизация.

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

бред полнейший. просто в 80-е ява ввела моду на использование байт-кода. никаких принципиальных изменений он не даёт, всё то же прекрасно работает хоть с ним, хоть без него. а байт-код использовался для реализации и паскаля, и смолтока, и бейсика — вы просто не знаете историю ФП

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

BZ>прочти всё же письмо целиком
И что?
Как это все отменяет твой наезд на байткод?

просто в 80-е ява ввела моду на использование байт-кода. никаких принципиальных изменений он не даёт

Тут

Автор: BulatZiganshin
Дата: 10.07.10

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

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

FR>То что к ним примешано управление памятью, конструкторы копирования, оператор присваивания, почему-то даже бородатые сишники
FR>в этих вещах путаются.
Загадка. Не знаю почему там можно путаться. Вроде ж простые вещи.

FR> Ну и конструкторы для нормального использования тянут за собой исключения, а это такое поле
Это совсем не обязательно. Можно пользоваться вообще без исключений.

FR>Про множественное наследование лучше промолчу.
Это тоже далеко не всегда надо да и если не выпендриваться то штука простая.

CC>>Ну и потом классы ещё не означают обязательное использование виртуальных функций. Да и нужны они далеко не всегда.
FR>Угу, только зачем тогда C++.
Т.е. для тебя С++ это обязательно виртуальные функции? Их и на plain C сделать несложно, возни только чуток больше.

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

FR>Если же делать правильно, то писать безопасный к исключениям код не тривиально.
Да ну! Тем более что исключения опять таки не обязательны. Их можно не использовать вовсе.

FR>>> Ну и во вторых я вообще не вижу смысла в "C с классами" при написании библиотек
CC>>И тем не менее он есть.
FR>Угу видел "шедевры".
"шедевров" спагетти кода написанного на Plain C я видел тоже достаточно, и что с того?
Программист в любом случае должен понимать что он делает и тот инструмент, которым он пользуется.

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

WH>Как это все отменяет твой наезд на байткод?
WH>

WH>просто в 80-е ява ввела моду на использование байт-кода. никаких принципиальных изменений он не даёт

во-первых, не могли бы вы перестать рассуждать в терминах наездов? :/

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

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


WH>А вот тут ты сильно не прав.
WH>Компиляция в байткод имеет убойные преимущества:
WH>1)Валидация кода на клиенте. Те я могу скачать какой угодно код и проверить его на вшивость простым алгоритмом. С нативным кодом такое не получится.

Это не преимущество байт кода, нативный код точно также может валидизироваться, но есть проблема с корявым x86 в котором разрешены не выровненые
прыжки. Если использовать специальный компилятор который выравнивает код плюс добавляет небольшие проверки все отлично валидизируется и для x86,
гугл это уже сделал для http://code.google.com/p/nativeclient/

как работает тут
http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdf

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

CC>Загадка. Не знаю почему там можно путаться. Вроде ж простые вещи.

Однако классическая ошибка с голыми указателями членами класса и без признаков конструктора копирования все время повторяется,
притом бывает и у опытных пользователей Си c классами.

FR>> Ну и конструкторы для нормального использования тянут за собой исключения, а это такое поле
CC>Это совсем не обязательно. Можно пользоваться вообще без исключений.

Угу это не будем использовать то тоже.

FR>>Про множественное наследование лучше промолчу.
CC>Это тоже далеко не всегда надо да и если не выпендриваться то штука простая.

Угу, только куда не плюнь все "вроде бы простое"

CC>>>Ну и потом классы ещё не означают обязательное использование виртуальных функций. Да и нужны они далеко не всегда.
FR>>Угу, только зачем тогда C++.
CC> Т.е. для тебя С++ это обязательно виртуальные функции? Их и на plain C сделать несложно, возни только чуток больше.

Нет, но если все запрещать тогда что вообще у тебя останется?

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

Угу, но не столько квалификации, сколько внимательности.

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

FR>как работает тут
FR>http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdf

Each component runs in its own private address space.

Дальше можно не читать.
Этим авторы расписались в том что они не могут толком валидировать нативный код.
Если бы могли то и этого требования бы небыло.

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

WH>Дальше можно не читать.

Какое это имеет отношение к верификации и валидации?

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

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

WH>Если бы могли то и этого требования бы небыло.

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

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

К>Снова стало модным придумывать новые языки?

"Одни языки создаются для решения задачи, другие — для доказательства той или иной точки зрения"
(C) Деннис Ритчи.

Это всегда было (и по всей видимости будет) "модным", т.к. ЯП — это лакомый кусочек, для интеллектуальных и зачастую слабоплодотворных дисскусиий, ибо доказывать свою точку зрения и оспаривать чужую, для многих людей представляется очень увлекательным времяпровождением.

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

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

WH>Дальше можно не читать.
WH>Этим авторы расписались в том что они не могут толком валидировать нативный код.
WH>Если бы могли то и этого требования бы небыло.
Странно, а как существует VMWare

Нативный код валидировать вполне можно. Но зачем? Проще сделать отдельное адресное пространство и заставить работать механизм защиты памяти — он для того и создавался.

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

C>Странно, а как существует VMWare
Осталось выяснить при чем тут VMWare.
Ты вообще по ссылкам то ходил?

C>Нативный код валидировать вполне можно. Но зачем? Проще сделать отдельное адресное пространство и заставить работать механизм защиты памяти — он для того и создавался.
Ну вон авторы native client'а пытаются что-то там валидировать вот только всеравно без изоляции адресных пространств не могут ничего сделать.

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

WH>>Дальше можно не читать.
FR>Какое это имеет отношение к верификации и валидации?
Прямое.
Это говорит о том что их "верификация" ничего не стоит.

FR>Это требование идет от браузеров у которых теперь в моде пускать на каждый плагин или страничку по отдельному процессу.
А почему это в моде?
А я тебе скажу: По тому что браузеры сами себе на право и на лево память разбивают.
native client также не предоставляет никаких средств по предотвращению порчи памяти.

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

C>>Странно, а как существует VMWare
WH>Осталось выяснить при чем тут VMWare.
Там валидируется нативный код.

WH>Ты вообще по ссылкам то ходил?
Да.

C>>Нативный код валидировать вполне можно. Но зачем? Проще сделать отдельное адресное пространство и заставить работать механизм защиты памяти — он для того и создавался.
WH>Ну вон авторы native client'а пытаются что-то там валидировать вот только всеравно без изоляции адресных пространств не могут ничего сделать.
Это можно сделать, и уже сделано в valgrind, qemu и VMWare. Просто в этом банально нет смысла, если достаточно защиты памяти. Зачем зря переделывать функциональность, которая есть в железке?

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

FR>>> Ну и конструкторы для нормального использования тянут за собой исключения, а это такое поле
CC>>Это совсем не обязательно. Можно пользоваться вообще без исключений.
FR>Угу это не будем использовать то тоже.
Ну дык во фразе "С с классами" нет "и с исключениями".

CC>> Т.е. для тебя С++ это обязательно виртуальные функции? Их и на plain C сделать несложно, возни только чуток больше.
FR>Нет, но если все запрещать тогда что вообще у тебя останется?
Не "запрещать" а "использовать только те фичи, что реально нужны".

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

FR>Первый вариант написан на OCaml (сильно что-то напоминает ) потом раскрутка на самом себе.

Что, тоже Dylan?

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

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