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

АХ>>Что ты под этим ("писать от типа") понимаешь? Я не очень понял. Можно пример?
L>Стандартный прием, который используется в Хаскеле, и который многократно видел поданный как совет в разных книжках статьях и прочее. Очень простой: "Если не ясно как должна выглядеть функция, сначала напиши её тип".

Это очень и очень напоминает Test-Driven Development, где собственно в качестве теста используется проверка на соответствие типа, но зато сразу осуществляется компилятором.

С Уважением, Andir!

Здравствуйте, Андрей Хропов, Вы писали:

АХ>1) скорость компиляции (взасчет локального, а не глобального анализа)

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

АХ>2) компонентность (в т.ч. интеграция с другими языками)

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

АХ>3) упрощение реализации Intellisense в IDE (по тем же причинам, что и 1) )

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

АХ>В общем я целиком за локальность и следующующую из нее компонентность.

Думаю, основной проблемой глобального вывода типов будет всё же сложность глобальности, а сложность использования глобального вывода типов. Возможность снести крышу выводу типов в зависимости от запутанности кода увеличивается экспоненциально. И это только первое измерение. Второе измерение — это ошибочность набиваемого кода. Это уже не просто экспоненциальность, а экспоненциальная экспоненциальность. Уже этого достаточно, чтобы программист и компилятор уставившись друг в друга могли бы до посинения повторять: man, what's the fuck is going on Глобальность лишь добавит в эти отношения ещё одно измерение, ещё один уровень сложности. В результате процесс выйдет из под контроля и банально потеряет всю свою ценность.

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


S>Это не решение. Это и есть проблема. Во-первых, понять вот эту концепцию виртуального и невиртуального наследования крайне трудно. А главное — зачем? Вот покажите мне хоть один жизненный пример смешивания виртуального наследования с невиртуальным!

Интерфейсы в Java, Delphi, C# — аналоги виртуального наследования С++.

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

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


M>>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.
S>Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.

А это пофиг. Оптимизация-то и инлайнинг происходят на ВЫЗЫВАЮЩЕЙ стороне. Т.е., даже если базовый метод уже "проджитен", он всё-равно может быть раскрыт в inline для конкретного места вызова. (для виртуальных машин рассуждения)

Курилка wrote:
> C>Собираюсь делать небольшой проект — портирование CLR на LLVM. Пока для
> C>него финансирование делаю.
> CLI наверное имеется в виду? Интересно было бы посмотреть, мы услышим
> где как и что потом? Внутренний проект? Или Open Source?
Проект будет внутренним OpenSource проектом

В результате ожидается получение простейшего компилятора (который будет
еще и JIT-компилятором), способного переводить сборки .NET в объектные
файлы LLVM.

VladD2 wrote:
>> > C>Даже параллельный конкуррентный GC вынужден на определенное время
>> > C>останавливать всех мутаторов. Оно достаточно короткое, но вполне
>> > C>существенное для многих целей.
>> > И что?
> C>Не всегда это терпимо. Хороший пример — игры. Вряд ли тебе будет
> C>приятно, если у тебя иногда игра будет на пару секунд зависать.
> У тебя отсуствует чувство реальности. Из своих же слов "на определенное
> время останавливать" ты почему-то сразу делаешь вывод "пару секунд
> зависать".
У меня есть эмпирические данные — мое приложение с кучей в 4Гб (кэш
объектов) зависает примерно на 0.5-5 секунды каждые полчаса. Это было
очень неприятно, так как одна остановившаяся нода нарушала репликацию во
всем кластере.

>> > C>Нормальный полный конкуррентный GC невозможен без аппаратной поддержки
>> > Это вопрос терминологии. К тому же конкуррентный и хорошо параллелящийся
>> > — это две большие разницы.
> C>Это я прекрасно знаю, поэтому и пишу "параллельный конкуррентный".
> Где? И зачем?
См. выделеное.

> C>Проблема в том, что для GC в том же .NET *не существует*
> C>иммутабельных объектов. Так как через reflection ты можешь поменять даже
> C>содержимое string. А значит, куча оптимизаций из Erlang GC идет лесом.
> Опять какие-то не относящиеся к делу аргументы. Я уже не говорю о том,
> что никакая рефлексия не мешает заниматься интернированием строк в
> донете.
Надеюсь, ты не будешь спорить о том, что интернация — это просто
оптимизация, которую применить можно очень редко, да которая еще и кривая?

> Мне просто интересно как все эта притянутая за уши фигня
> помешает мне создать удобный фрэймворк для распараллеливания некоторого
> класса задач?
Не помешает. В Скале так и сделали. Просто его перформанс часто будет
сильно уступать специализированым VM.

>> > О изменениях VM пока что можно только мечтать.
> C>Я сейчас финансирование на CLR для LLVM провожу. Так что я могу и мечтать
> Давай сделаем так. Если в друг твои мечты станут реальностью и ты
> доведешь это дело хотя бы до состояние бэты, то тогда и погворим. А
> потка ваши мечты и домысли не должны быть основанием для рассуждений,
> просто потому что они виртуальны.
Да без проблем

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

Собственно, я сначала хотел портировать N. на LLVM, чтобы сделать потом
на нем аналог Эрланга и добавить туда фичи типа RI для управления
памятью. Потому как Эрланг работает неплохо, но на контроллерах с 170MHz
уже слишком медленно.

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

A>Это очень и очень напоминает Test-Driven Development, где собственно в качестве теста используется проверка на соответствие типа, но зато сразу осуществляется компилятором.

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

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

C>У меня есть эмпирические данные — мое приложение с кучей в 4Гб (кэш
C>объектов) зависает примерно на 0.5-5 секунды каждые полчаса.

Оно крутится на дотнете? На каком типе GC?

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Чего ? Любой человек, кто в школе хотя бы немного видел математику (я думаю, что все-таки подавляющее большинство людей у нас в стране имеет хотя бы среднее образование) читает конструкции вида sin(x-1)*x совершенно однозначно.

Ага и совершенно не так как это требует синтаксис Хаскеля.

А конструкция sin x — 1 будет точно так же однозначно понята как (sin * x) — 1.

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

L>Так елки-палки, чего ж общаешься то? Конструктива то нет и не предвидится.

+1

Потому отвечать на выпады не буду.

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

IT>Компонентность тут вообще никак не пострадает, т.к. скомпилированный метод уже будет выведен, либо просто не скомпилируется.

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

VladD2 wrote:
> C>У меня есть эмпирические данные — мое приложение с кучей в 4Гб (кэш
> C>объектов) зависает примерно на 0.5-5 секунды каждые полчаса.
> Оно крутится на дотнете? На каком типе GC?
Sun JVM, конкурентный параллельный инкрементальный GC. Если интересно,
то могу посмотреть конкретные настройки.

Проблема в том, что объектный кэш разделяется между всеми потоками
(даже, по сути, между всеми узлами кластера), да еще и постоянно
меняется, так как он служит чем-то вроде базы данных в памяти. Если
интересно, то этот кэш — это http://www.tangosol.com/coherence-overview.jsp

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

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

C>Sun JVM, конкурентный параллельный инкрементальный GC.

Что и следоволо ожидать.

C>Если интересно,
C>то могу посмотреть конкретные настройки.

Нет, его проблем не интересуют. Просто не надо обобщать одну реализацию на все в целом.

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

VD>Ты и еще EvilChild — это две личности при назговоре с которыми у меня все мысли почему-то все время фокусируются на вопросе вменяемости этих личностей.

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

VladD2 wrote:
> C>Sun JVM, конкурентный параллельный инкрементальный GC.
> Что и следоволо ожидать.
Как будто .NETвый GC сильно лучше.

> C>Если интересно,
> C>то могу посмотреть конкретные настройки.
> Нет, его проблем не интересуют. Просто не надо обобщать одну реализацию
> на все в целом.
Пока что Sun'овский GC — самый лучший, особенно если его настроить
правильно. По секрету скажу, что .NETовый GC загибается на 16
процессорах, а Sun'овский спокойно работает на 32. Данные вот от этих
товарищей: http://www.tangosol.com/coherence-.net.jsp

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

IT>>Компонентность тут вообще никак не пострадает, т.к. скомпилированный метод уже будет выведен, либо просто не скомпилируется.

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

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

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

C>Как будто .NETвый GC сильно лучше.

Секундных задержек точно не замечано.

VladD2 wrote:
> C>Как будто .NETвый GC сильно лучше.
> Секундных задержек точно не замечано.
Вполне заметно для некоторых сценариев использования.

Тут все зависит от вида графа объектов и их разделению между потоками.
Если каждый поток будет работать в основном со своими данными, то пауз
почти не будет — так как мусоросборщику не надо будет останавливать все
потоки (.NETовый и JVMные сборщики используют механизм защиты памяти для
остановки потока, если он обращается к данным, с которыми сейчас
работает GC). Точно так же, если данные будут не очень сильно связные,
то упаковщик пройдет по ним достаточно быстро и паузу можно не заметить.

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

Я мониторил GC — сначала он достаточно долгое время использует полностью
конкуррентный mark&sweep (для старшей кучи, молодое поколение не
рассматриваем), но постепенно куча фрагментируется и он запускает
упаковщик. А это как раз и дает паузу.

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

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

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

A>Если на C++ получается писать только хлам — что ж, это выход

Основную проблему C++ я вижу в том, что он не безопасен by design. Это как запорожец ( C ), затюненный (++) под мерседес. (Но ведь это всё равно запорожец) Почему бы, спрашивается, сразу не выбрать мерседес? Очевидно, гораздо дешевле писать на привычном C++, а потом сказать, что это самый безопасный продукт за всю историю человечества. Java и .NET, конечно, хорошо, но какая-то часть кода всё равно должна быть нативной. Особенно, если это системный код. И вот тут-то, в самых критических местах до сих пор используется Це-баг-баг! (Если не сам Це, что не лучше)

Я слышал такие аргументы в сторону C++, что продвинутый человек может обходить все грабли, зная о них. В качестве контраргумента приведу начало из Cyclone: A Type-Safe Dialect of C :

If any bug has achieved celebrity status, it is the
buffer overflow. It made front-page news as early
as 1987, as the enabler of the Morris worm, the first
worm to spread through the Internet. In recent years,
attacks exploiting buffer overflows have become more
frequent, and more virulent. This year, for exam-
ple, the Witty worm was released to the wild less
than 48 hours after a buffer overflow vulnerability
was publicly announced; in 45 minutes, it infected
the entire world-wide population of 12,000 machines
running the vulnerable programs.
Notably, buffer overflows are a problem only for the
C and C++ languages—Java and other “safe” lan-
guages have built-in protection against them. More-
over, buffer overflows appear in C programs written
by expert programmers who are security concious—
programs such as OpenSSH, Kerberos, and the com-
mercial intrusion detection programs that were the
target of Witty.
This is bad news for C. If security experts have
trouble producing overflow-free C programs, then
there is not much hope for ordinary C program-
mers. On the other hand, programming in Java is
no panacea; for certain applications, C has no com-
petition. From a programmer’s point of view, all the
safe languages are about the same, while C is a very
different beast.

Ну и, например, такой комментарий :

Firefox security holes

There’s a new version of Firefox out (1.5.0.2), with fixes for 22 security issues, according to Secunia. My favorite is this one:

2) An error in the garbage collection in the JavaScript engine can be exploited to cause a memory corruption.

Successful exploitation may allow execution of arbitrary code.

Apparently garbage collectors are not perfect! Who knew.

Among the 22 issues there are a bunch that would clearly be prevented by a safe language like Cyclone:

3) A boundary error in the CSS border rendering implementation may be exploited to write past the end of an array.

4) An integer overflow in the handling of overly long regular expressions in JavaScript may be exploited to execute arbitrary JavaScript bytecode.

6) An error in the “InstallTrigger.install()” method can be exploited to cause a memory corruption.

13) An error in the processing of a certain sequence of HTML tags can be exploited to cause a memory corruption.

Successful exploitation allows execution of arbitrary code.

15) Some errors in the DHTML implementation can be exploited to cause a memory corruption.

Successful exploitation may allow execution of arbitrary code.

16) An integer overflow error in the processing of the CSS letter-spacing property can be exploited to cause a heap-based buffer overflow.

Successful exploitation allows execution of arbitrary code.

Some of the others might be safety issues as well, but it takes quite a bit of digging to figure these things out.

14 April 2006 by trevor

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

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

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

Я считаю, целостность — минимальное требование. Поэтому C/C++ я считаю хламом. Историческую функцию они исполнили (когда нужно лишь бы работало). Я считаю, нужно давно что-то менять. Вы можете признавать это, можете нет, это ваше дело.

Взять в качестве только D, я считаю, сильное ограничение. Почему D? Почему не Eiffel или Ada? Потому что на C похож (первое, что в глаза бросается)? Думаю, список должен быть шире. Вроде есть соседний топик "альтернативные" языки, но там альтернативность больше по ориентированности (ФП, ЛП) просвечивает, здесь же явно выраженная императивность.

Небольшие проги ещё на Cyclone можно писать.

Трудность в том, что непонятно, с какой стороны делать переход. Когда требования спускаются сверху, и требуется просто зарабатывать деньги (трое детей в семье, не считая собаки) на C/C++, тут трудно что-то изменить. А те, кто спускают требования, преследуют другие цели. Покупателю (в своей массе) не важно, как сделано, главное, как работает. Порочный круг.

Потенциальный выход я вижу в школьниках и студентах. Чему их сейчас учат? Вот на том они и пишут. В массе, опять же, в массе.

Приход Эйфеля в Россию я пока не наблюдаю. А вот у Ады есть шансы!

Ада — идеальный базовый язык образования в области информационных технологий

По настоящему важными, однако, являются следующие соображения: насколько данный
язык облегчает профессиональное изложение учебного материала и насколько он облегчает
усвоение студентами совокупности учебных дисциплин. Среди этих причин – привычки и
квалификация преподавателей, доступность литературы, изданной на бумажных носителях и
на русском языке, личные предпочтения тех, кто разрабатывает (или утверждает!) учебно-
квалификационные программы специальностей и рабочие программы конретных курсов, пред-
ставления о том, что в данный момент наиболее востребовано рынком труда. Сплошь и рядом
мы имеем совершенно ненормальные ситуации, когда основной (и нередко математизирова-
ный) курс по алгоритмам и структурам данных поддерживается ... языком Си, курс по парал-
лельному программированию и системам реального времени основывается на Джаве (которая
не для этих областей проектировалась и создавалась), а курс по методам разработки и сопро-
вождения больших программных систем использует в качестве языка сопровождающего прак-
тикума, извините, Паскаль-Дельфи. В результате существенная часть времени и сил тратится
на попытки разглядеть алгоритм (а еще того сложнее – структуру данных!) через криптогра-
фический синтаксис Си или, скажем, на то, чтобы отделить проблемы адресной арифметики от
логических и математических проблем организации сортировки и поиска. Или (в курсах по
параллельному программированию) возиться с тем, чтобы правильно переключать семафоры
и вовремя посылать сигналы (от чего всеми силами стремится уйти реальная программная ин-
дустрия!) вместо того, чтобы выделять процессы и разрабатывать модели их взаимодействия
высокоуровневыми средствами, допускающими эффективный статический и динамический
контроль. Еще конфузливей «освоение методов» проектирования и разработки больших про-
ектов и систем средствами Дельфи, предназначенной только (и в этом качестве действительно
широко и эффективно используемой) для быстрого прототипирования и создания графических
интерфейсов конкретно под Виндоуз. При этом такими реальностями больших проектов, как
полиплатформенные стандарты, Юникс-ориентированные инструменты, лицензионная чисто-
та, разумеется, даже не пахнет.

Я из приведённых мной языков (добавьте свои варианты по вкусу, например, Erlang) наивысший приоритет отдаю Аде, потому что это язык универсальный и при этом сравнительно разработанный. Из всех перечисленных языков только Ада входит в main GCC distribution. gcc и так для меня важный инструмент, а тут ещё Ада в основной поставке. Это удобно.

К тому же, GNAT осваивает .NET.

Это значит, переносимый код для нативных и управляемых сред. Удобно, не правда ли?

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

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

[..умные и конструктивные высказывания пропущены, но учтены...]

OCT>Взять в качестве только D, я считаю, сильное ограничение. Почему D? Почему не Eiffel или Ada? Потому что на C похож (первое, что в глаза бросается)? Думаю, список должен быть шире. Вроде есть соседний топик "альтернативные" языки, но там альтернативность больше по ориентированности (ФП, ЛП) просвечивает, здесь же явно выраженная императивность.

Для static typed и native языка я не вижу в нем каких либо ограничений. И в конце концов, в мире же существуют какие-то стандарты, даже точнее не стандарты а культура. Почему возникло так много C подобных языков — потомучто большинству программистов, в силу естественного опыта, их проше воспринимать. А если вы С++ программист и я С++ программист, что может быть лучше редизайнутого С подобного языка, такого как D.

Здравствуйте, vdimas, Вы писали:
V>Интерфейсы в Java, Delphi, C# — аналоги виртуального наследования С++.
В третий раз повторяю: покажите мне жизненный пример, где есть "один виртуальный A и по одному невиртуальному A для каждого невиртуального пути наследования к A".
Кроме того, интерфейсы никак не являются аналогом виртуального наследования. У виртуального наследования аналогов нет.

V>Если наследовать интерфейсы, то да, достаточно лишь виртуального наследования. Но если охота наследовать реализации (вместе с данными/полями), то вид наследования определяет способ агрегирования базы. В принципе, ничего сложного в этом нет, один раз схема и стрелочки на бумаге рисуются и даже студенты моментально улавливают суть.
Не надо мне рассказывать, что такое виртуальное/невиртуальное наследование. Я в курсе. А у студентов, "моментально уловивших суть", я принимал экзамены по С++.

V>А это пофиг. Оптимизация-то и инлайнинг происходят на ВЫЗЫВАЮЩЕЙ стороне. Т.е., даже если базовый метод уже "проджитен", он всё-равно может быть раскрыт в inline для конкретного места вызова. (для виртуальных машин рассуждения)
Что-то сомневаюсь. Компилятор не имеет права инлайнить виртуальный метод, т.к. он может быть перегружен в одном из потомков.