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

Ваши мнения?

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

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

А мне наоборот непонятно, зачем плодить универсальные языки. К тому же я с трудом представляю, как можно объединить в одном языке достоинства C++, Prolog, Haskell и, скажем, Perl.

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

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

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

А>А мне наоборот непонятно, зачем плодить универсальные языки. К тому же я с трудом представляю, как можно объединить в одном языке достоинства C++, Prolog, Haskell и, скажем, Perl.
Полностью согласен

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

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

IO>Ваши мнения?

Вот тебе первая философская мысль:
Действительно непонятно зачем это надо делать — помоему надо ставить не на новые гипер универсальные языки, а
на переносимые технологии — посмотри к чему щас все идет — появляются новые технологии, а потом пишутся их реализации на разных языках
ИМХО, не надо плодить новых языков — советую еще сходить по этой ссылке и посмотреть на один универсальный язык
http://www.newarchitectmag.com/documents/s=2457/new1011393632235/

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

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

Уже говорили об этом. Принципиально невозможно.

Один хочет чтобы можно было писать while(*p++ = *q++);
а другой требует, чтобы так нельзя было писать. Точка.

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

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

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

IT>Уже говорили об этом. Принципиально невозможно.

IT>Один хочет чтобы можно было писать while(*p++ = *q++);
IT>а другой требует, чтобы так нельзя было писать. Точка.

Думаю вы избираете неверный путь. Этот путь уже объезжен многими.
Могу доказать научно, что универсальный язык не может быть эффективным языком!!!

Откровенно говоря, я начал свой проект (если кто-то слышал XASM)
То есть направление такое, создать не язык программирования, а нечто совершенно другое...

IO>Ваши мнения?
Предлагаю потратить эту энергию в мирных целях.
Например, в целях собственного обогашения. Или образования — в целях дальнейшего обогащения.

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

IO>Идея такая:
IO>развернуть обсуждение о создании нового языка программирования между довольно опытными программистами разных специализаций. На выходе получить концепцию языка, удовлетворяющего всех.
IO>Причем начать можно с самых общих (почти философских вещей).

Когда-то хотели создать универсальный язык — Эсперанто... Создать-то создали...

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

Лексики? Синтаксиса? Семантики?

IO>Т.е. основная концепция должна быть достаточно универсальна (микро-ядро)?

IO>Ваши мнения?

Ох, и передерутся же собравшиеся на обсуждение... :down:

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

IT>>Уже говорили об этом. Принципиально невозможно.
IT>>Один хочет чтобы можно было писать while(*p++ = *q++);
IT>>а другой требует, чтобы так нельзя было писать. Точка.
Давайте точек не ставить. Нет нерешаемых проблем. Если несложно дайте ссылку на этот разговор.

E>Могу доказать научно, что универсальный язык не может быть эффективным языком!!!
Будьте добры, докажите. Хотя бы общие соображения, если формальное доказательство слишком громоздкое.

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

Всем: машин много разных, но тем не менее у всех стоит двигатель внутреннего сгорания (и на легковых и на грузовых и т.д.).

IO>Нет нерешаемых проблем.

Sure?

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

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

IT>>>Уже говорили об этом. Принципиально невозможно.
IT>>>Один хочет чтобы можно было писать while(*p++ = *q++);
IT>>>а другой требует, чтобы так нельзя было писать. Точка.
IO>Давайте точек не ставить. Нет нерешаемых проблем. Если несложно дайте ссылку на этот разговор.

E>>Могу доказать научно, что универсальный язык не может быть эффективным языком!!!
IO>Будьте добры, докажите. Хотя бы общие соображения, если формальное доказательство слишком громоздкое.

Например: "Закон систем"

Чем система больше, тем меньше каждая её часть знает о системе.

Или: "Принцип сохранения..."

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

При этом выполняетсья след зависимость:

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

Но!!!!!!!!!!!

Чем более язык полнее описывает данную область: значит описывает все комбинации представления информации -- тем будут меньше потери информации при преобразовании (здесь преобразование это перевод в машинные коды)

Примеры: Язык SQL -- как спец язык имеет потенциал 90% соответствия с "идеальным кодом"
Где "идеальный код" -- это максимально эффективный код, из всех возможных вариантов реализации.

Надеюсь это было достаточно понятно.

E>>Откровенно говоря, я начал свой проект (если кто-то слышал XASM)
E>>То есть направление такое, создать не язык программирования, а нечто совершенно другое...
IO>Очень интерестно было бы ознакомиться.

Давай в приват, эта тема не для форума, слишком идея новая

EdmondXASM@mail.ru

IO>Всем: машин много разных, но тем не менее у всех стоит двигатель внутреннего сгорания (и на легковых и на грузовых и т.д.).

Видители, у меня такое чувство, что Вы раздраженны. Понимаю, ещё и как, понимаю.
Когда я выбрасил свою тему про XASM там такое заширудилось... ООО!!!

Существует большое количество языков программирования, но наиболее популярны сейчас диалекты C/C++. Реально удобный язык, в меру переносимый, короче всем хорош. Даже UNIX на нем от и до написан. На каком еще языке есть реализованные операционные системы?

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

Короче это я про то, что возникают новые задачи для которых надо придумывать новые средства реализации. А для того, что уже есть нечего и городить. А идея может быть такая: создать среду для написания объектов (XML inside?), которая будет их преобразовывать в C++/C#/Java или еще чего.

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

H>Существует большое количество языков программирования, но наиболее популярны сейчас диалекты C/C++. Реально удобный язык, в меру переносимый, короче всем хорош. Даже UNIX на нем от и до написан. На каком еще языке есть реализованные операционные системы?
На ассемблере

H>Короче это я про то, что возникают новые задачи для которых надо придумывать новые средства реализации. А для того, что уже есть нечего и городить. А идея может быть такая: создать среду для написания объектов (XML inside?), которая будет их преобразовывать в C++/C#/Java или еще чего.
А чем тебя CLR не устраивает?

... Янус версия 1.0 alpha 2

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

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

H>>Существует большое количество языков программирования, но наиболее популярны сейчас диалекты C/C++. Реально удобный язык, в меру переносимый, короче всем хорош. Даже UNIX на нем от и до написан. На каком еще языке есть реализованные операционные системы?
AVK>На ассемблере

От процессора зависит сильно

H>>Короче это я про то, что возникают новые задачи для которых надо придумывать новые средства реализации. А для того, что уже есть нечего и городить. А идея может быть такая: создать среду для написания объектов (XML inside?), которая будет их преобразовывать в C++/C#/Java или еще чего.
AVK>А чем тебя CLR не устраивает?

Меня и CLR устраивает и MIDP явовская и много чего еще, только стремление создавать программы за минимальное время и чтобы они делали то, что надо с этим никак не связано. Вот например сборка мусора в памяти, она позволяет уменьшить время потраченное на поиск разных утечек в памяти. Это реальный эффект. Что еще можно вспомнить на эту тему? Из вот таких нюансов и можно получить быстрое и надежное программирование.

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

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

H>>Существует большое количество языков программирования, но наиболее популярны сейчас диалекты C/C++. Реально удобный язык, в меру переносимый, короче всем хорош. Даже UNIX на нем от и до написан. На каком еще языке есть реализованные операционные системы?
AVK>На ассемблере

Не тянет на идеальный язык

H>>Короче это я про то, что возникают новые задачи для которых надо придумывать новые средства реализации. А для того, что уже есть нечего и городить. А идея может быть такая: создать среду для написания объектов (XML inside?), которая будет их преобразовывать в C++/C#/Java или еще чего.
AVK>А чем тебя CLR не устраивает?

Хрен (.NET) редьки (Java2) не слаще !

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

AVK>>На ассемблере
А>От процессора зависит сильно
Тем не менее ОС на нем писали и пишут.

AVK>>А чем тебя CLR не устраивает?

А>Меня и CLR устраивает и MIDP явовская и много чего еще, только стремление создавать программы за минимальное время и чтобы они делали то, что надо с этим никак не связано. Вот например сборка мусора в памяти, она позволяет уменьшить время потраченное на поиск разных утечек в памяти. Это реальный эффект. Что еще можно вспомнить на эту тему? Из вот таких нюансов и можно получить быстрое и надежное программирование.
Проблема в том что очень сложно создать одновременно универсальное и эффективное средство. Если мы хотим сделать что то хорошо и быстро инструментарий приходится затачивать под конкретную задачу. А так, безотносительно предметной области, никакого смысла в подобных разговорах нет.

... Янус версия 1.0 alpha 2

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

AVK>>На ассемблере
H>Не тянет на идеальный язык
А я и не говорил что он идеальный.

H>Хрен (.NET) редьки (Java2) не слаще !
Ну все таки немножко послаще, особенно в плане быстродействия.

... Янус версия 1.0 alpha 2

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

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

IO>Ваши мнения?
В чем-то это даже интересно. Мы как раз над этой проблемой работаем. Первый язык был нами разработан в 98 году, он был ориентирован на Геоинформационные системы. Сейчас мы заняты тем, что пытаемся усовершенствовать «наш» язык, чтобы с помощью него можно было решать задачи в различных отраслях народного хозяйства.

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

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

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

А насчет while(*++q = *++p) , так ведь чаще проблема не в том, что не нравится стиль. Часто программист просит, дайте мне хоть #/./s.p-/.i. , лишь бы работало и решало мою задачу.

Конечно же, программируя на C++ я могу гордиться, мол моя программа будет даже на Sparc работать. Только будет это слишком самонадеяно, а самое главное: кто из нас Спарк хотя бы раз видел и трогал в живую?

Предлагаю продолжить обсуждения, а то как-то даже немного обидно.

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

P>Быстро как-то заглохло ваше обсуждение.
P>Нарвусь на оскорбления, но по-моему было высказано много чужих мыслей не своими же словами.
Да, это весьма смелое высказывание — наверное не следует обобщать, правильнее наверное говорить конкретнее.

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

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

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

P>А насчет while(*++q = *++p) , так ведь чаще проблема не в том, что не нравится стиль. Часто программист просит, дайте мне хоть #/./s.p-/.i. , лишь бы работало и решало мою задачу.
Ну это наверное не совсем так — определенно считаю, что стиль значит очень много

P>Конечно же, программируя на C++ я могу гордиться, мол моя программа будет даже на Sparc работать. Только будет это слишком самонадеяно, а самое главное: кто из нас Спарк хотя бы раз видел и трогал в живую?
Я могу с гордостью заявить что видел и писал под него — ну так ничего особенного.

P>Предлагаю продолжить обсуждения, а то как-то даже немного обидно.
Ну вроде бы все еще в процессе

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

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

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

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

P>А насчет while(*++q = *++p) , так ведь чаще проблема не в том, что не нравится стиль. Часто программист просит, дайте мне хоть #/./s.p-/.i. , лишь бы работало и решало мою задачу.

P>Конечно же, программируя на C++ я могу гордиться, мол моя программа будет даже на Sparc работать. Только будет это слишком самонадеяно, а самое главное: кто из нас Спарк хотя бы раз видел и трогал в живую?

P>Предлагаю продолжить обсуждения, а то как-то даже немного обидно.

Если так хочешь — пожалуста — давай излагай свои идеи по реализации, будем спорить, а потом посмотрим что получится

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

H>>Хрен (.NET) редьки (Java2) не слаще !
AVK>Ну все таки немножко послаще, особенно в плане быстродействия.

Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++. Так зачем более универсальный, но и более медленный язык?

С>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++. Так зачем более универсальный, но и более медленный язык?

Ты наверное, хотел сказать — МЕНЕЕ универсальный?
И что — неужели не можешь себе представить, чем БОЛЕЕ МЕДЛЕННЫЙ и МЕНЕЕ УНИВЕРСАЛЬНЫЙ язык может быть лучше более быстрого и более универсального?

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

С>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++. Так зачем более универсальный, но и более медленный язык?

Неужели? Интересно, чем вызвана такая уверенность

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

С>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++.
На основании чего ты сделал такие выводы?

С> Так зачем более универсальный, но и более медленный язык?
На данный момент быстрота не самый важный критерий компилятора.

... Янус версия 1.0 alpha 3

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

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

С>>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++. Так зачем более универсальный, но и более медленный язык?

IT>Неужели? Интересно, чем вызвана такая уверенность
Не могу привести сейчас ссылки, но я читал, что исполняемый модуль программы, написанной с использованием С.# вырастает по сравнению с программой, написсаной на С/С++, и скорость выполнения падает. Кроме того всякие механизмы типа сборки мусора не могут быть всегда эффективными, потому как один раз написаны и изменению не подлежат.

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

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

С>>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++.
AVK>На основании чего ты сделал такие выводы?

С>> Так зачем более универсальный, но и более медленный язык?
AVK>На данный момент быстрота не самый важный критерий компилятора.

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

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

С>Не могу привести сейчас ссылки, но я читал, что исполняемый модуль программы, написанной с использованием С.# вырастает по сравнению с программой, написсаной на С/С++,
Вырастает в смысле размера файла? Ну это полный бред.
С> и скорость выполнения падает.
Как показывают тесты, не особо она и падает, а кое где возрастает.

С> Кроме того всякие механизмы типа сборки мусора не могут быть всегда эффективными, потому как один раз написаны и изменению не подлежат.
Неээфективность GC сказыватся только на объеме потребляемой памяти. Падать быстродействие будет только при нехватке памяти.

... Янус версия 1.0 alpha 3

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

С>>> Так зачем более универсальный, но и более медленный язык?
AVK>>На данный момент быстрота не самый важный критерий компилятора.

С>Я имею ввиду не работу компилятора, а работу готовой программы.
Так и я про скорость работы готовой программы.

С> Так вот весь мир стремится убыстрить свое производство,
И производство софта в том числе, заметь.

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


... Янус версия 1.0 alpha 3

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

С>Не могу привести сейчас ссылки, но я читал, что исполняемый модуль программы, написанной с использованием С.# вырастает по сравнению с программой, написсаной на С/С++, и скорость выполнения падает. Кроме того всякие механизмы типа сборки мусора не могут быть всегда эффективными, потому как один раз написаны и изменению не подлежат.

Я не буду утверждать, что быстродействие программ написанных на C# намного больше чем у C++, для этого нужно делать серьёзный комплексный тест, ставя в равные условия обе среды выполнения, что практически невозможно. Но я могу тебя заверить, что быстродействие C# не меньше чем в C++, для этого просто нет причин.

За GC я могу точно сказать, что эта схема работает быстрее чем C++ и Windows хипы в несколько раз для 95% задач. Это дело я это долго и нудно проверял.

Скорее всего ты это сказал не подумав или почитав не очень компетентный источник. У CLR есть следующие недостатки в плане ресурсоёмкости, которые, если на них посмотреть с другой стороны, являются большими достоинтсвами:

• JIT-компиляция. Проблема в том что программа в памяти занимает место дважды, первый раз p-код, второй раз откомпилированный native-код. К тому же, так как компиляция каждой функции производится в момент её первого вызова, то программа заметно тормозит при старте. Обе проблемы устраняются путём предварительной компиляции программы при установки или с помощью ngen.exe.
  
• Весь runtime программы грузится вместе с ней, в отличии от Windows программ, для которых большинство необходимых библиотек грузится ещё во время старта операционки.

Т.е. можно говорить только о проблеме потребления ресурсов, но никак не о быстродействии. В конце концов оптимизаторы и для C# и для C++ писались одной и той же конторой

[skipped], но все очень грамотно оспорено.

P>Если так хочешь — пожалуста — давай излагай свои идеи по реализации, будем спорить, а потом посмотрим что получится

Вот это другое дело.

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

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

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

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

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

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

Собственно, чего хочется:
+ иметь в свойствах аттрибуты, функции и вложенные свойства;
+ уметь добавлять аттрибуты в существующий объект, как в дерево, перенеся удобство иерархических структур из области проектирования, в область исполнения;
+ уметь быстро этот объект вынуть;
+ позволять классам инстанцировать объекты по-разному, в зависимости от того, где будет определен объект, и уметь прозрачно конвертить разные варианты друг в друга;
+ позволить себе навводить кучу собственных именованных операторов (еще Страуструп хотел);
+ разрешить себе, наконец, дополнять библиотечные классы новыми возможностями без использования наследования (с целью обмана дочерних программ и для дополнения функциональности различных контейнеров и потоков, незаметно для них самих и других библиотек);
+ из верхнего вытекает: разрешить программе работать со старыми (или неожиданно слишком новыми) версиями библиотек, жонглируя адресами аттрибутов при старте программы;
+ само собой теперь уже нужен Reflection;
+ после всего верхнего, никак не обойтись без разграничения, все-таки, семантик владения и использования;
+ еще кое-чего совсем бредового...

продолжаем разговор

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

P>продолжаем разговор
Я бы предложил ввести паттерны как элементы языка. Эдакие супер-шаблоны. Т.е. есть средства описания паттерна похожие на средства описания шаблона. Есть механизмы задания их параметров. И есть библиотека стандартных паттернов. В общем в итоге можно будет писать жутко лаконичные программы.
Если вдуматься то 95 процентов ручного программного кода можно классифицировать на небольшое количество классов. И думается что теоретически возможно по небольшому описанию раскручивать эти классы кода до реального кода.
Еще интересна была бы встроенная в язык кодогенерация (код имеется ввиду исходный). Т.е. такие супер-макросы, завязанные на синтаксис и семантику языка и на его рантайм.

... Янус версия 1.0 alpha 3

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

P>>продолжаем разговор
AVK>Я бы предложил ввести паттерны как элементы языка. Эдакие супер-шаблоны.

Хочу такой паттерн, который бы не позволял постить сообшения в форум, если в оном сообщении новый текст не отбит пробельной строкой от квотируемого

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


P>Собственно, чего хочется:
P>+ иметь в свойствах аттрибуты, функции и вложенные свойства;
P>+ уметь добавлять аттрибуты в существующий объект, как в дерево, перенеся удобство иерархических структур из области проектирования, в область исполнения;
Эти два пункта позволяет реализовать Python

P>+ уметь быстро этот объект вынуть;
Вот тут надо уточнить, кто будет отвечать за уничтожение объектов — сами объекты или же некоторый поток типа сборщика муссора, либо отдельный контроллер.

P>+ позволять классам инстанцировать объекты по-разному, в зависимости от того, где будет определен объект, и уметь прозрачно конвертить разные варианты друг в друга;
Ну уж это точно Python позволяет делать

P>+ позволить себе навводить кучу собственных именованных операторов (еще Страуструп хотел);
Хотел — это помню

P>+ разрешить себе, наконец, дополнять библиотечные классы новыми возможностями без использования наследования (с целью обмана дочерних программ и для дополнения функциональности различных контейнеров и потоков, незаметно для них самих и других библиотек);
P>+ из верхнего вытекает: разрешить программе работать со старыми (или неожиданно слишком новыми) версиями библиотек, жонглируя адресами аттрибутов при старте программы;
Ну чтож — это то нетрудно, но вот как быть с моделью безопасности

P>+ само собой теперь уже нужен Reflection;
P>+ после всего верхнего, никак не обойтись без разграничения, все-таки, семантик владения и использования;
P>+ еще кое-чего совсем бредового...

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


P>продолжаем разговор
поехали

Здравствуйте AndrewVK.

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

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

IT>Хочу такой паттерн, который бы не позволял постить сообшения в форум, если в оном сообщении новый текст не отбит пробельной строкой от квотируемого

Вы хоть определитесь в конце концов. А то один говорит что пробельные строки удалять надо, другой что ставить. У тебя что, квотирование не подствечивается?

... Янус версия 1.0 alpha 3

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

P>Здравствуйте AndrewVK.

P>Ну то есть, в целом мечта понятна, а вот в частностях нет.

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

P> И потом, не вполне ясно различие между кодогенерацией и паттернами.
Можно сказать так — кодогенерация это более общий случай. Вполне возможно что паттерны можно реализовать на основе кодогенерации.

P> С кодогенерацией, по-моему, нужно подумать отдельно. Нагружать систему невнятными спецификациями особых регулярных выражений будет, вроде, неправильно совсем. А если попользовать шаблоны, то в них очень не хватает перегруженного оператора . , который бы в качестве аргументов принимал параметры аттрибута или метода и, искорежив их, разворачивался нужное кол-во раз внутри тела класса.

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

... Янус версия 1.0 alpha 3

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


AVK>Не, немножко не так. Кодогенерация — быстрый и удобный способ создавать классы на лету, с поддержкой со стороны языка. Шаблоны же живут исключительно в компайл-тайм.

Глупости, простите-извините. Никто не мешает нам использовать Reflection для run-time инстанцирования
И вообще, давайте смотреть на вопросы ширше, не оборачиваясь каждый раз на то, как та или иная идея реализована в C++. А вот насчет поддержки — давайте предлагать варианты синтаксиса и четких механизмов функционирования.

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

С>>>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++.
AVK>>На основании чего ты сделал такие выводы?

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

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

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

SS>Вот именно, программисты тоже хотят убыстрить свою работу. На C# скорость разработки увеличивается в разы по сравнению с C++, на значительном большинстве современных задач.

Полностью с этим согласен, но не думаю, что для этого необходим новый универсальный язык, на котором новенький "программист" после полугодового курса сможет писать дешёвый софт, внешне похожий на профессиональные программы. Достаточно вспомнить Visual Basic, на котором фантастически быстро можно собрать что-либо вроде копировщика файлов, с интерфейсом, как у Visual Studio. Ничего не имею против VB или C.#, а также новых технологий. Просто моё мнение, что новый супер универсальный язык подойдёт разве что системным администраторам для быстрого сляпывания простых приложений.

Я также внимательно прочитал все ответы на моё высказывание относительно С.#. Признаю свою ошибку, доказательства довольно весские. Но при этом сабже дискуссия уходит в сторону. А что касается нового языка, то его необходимо с самого старта снабжать очень удобной средой разработки ( иначе не получится быстрого программирования ) и целым ворохом принципиально новых библиотек ( иначе конечный продукт сможет конкурировать разве что с приложениями из-под VB 6-й версии).
Так что если господа разработчики располагают достаточным количеством времени, то возможно оно того и стоит.

Спасибо за внимание.

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

С>... А что касается нового языка, то его необходимо с самого старта снабжать очень удобной средой разработки ( иначе не получится быстрого программирования ) и целым ворохом принципиально новых библиотек ( иначе конечный продукт сможет конкурировать разве что с приложениями из-под VB 6-й версии).

Как раз это совсем не нужно. .NET Framework прекрасно демонстрирует как несколько языков могут ужиться в одной среде и использовать одни и те же библиотеки. Если новый язык будет поддерживать CLR, то всё это он получит бесплатно.

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

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

IT>Как раз это совсем не нужно. .NET Framework прекрасно демонстрирует как несколько языков могут ужиться в одной среде и использовать одни и те же библиотеки. Если новый язык будет поддерживать CLR, то всё это он получит бесплатно.

IT>Кстати, весь этот разговор не имел бы смысла, если бы не этот факт. Не исключено, что в скорости появятся клоны и усовершенсвтвования того же C#, именно по той причине, что можно сконцетрироваться только на языке и разрабатывать его в условиях уже готового и отлаженного окружения.

Я немного не понял. Здесь идёт обсуждение создания принципиально новой концепции языка или новой надстройки над новой, ещё не до конца развитой технолигией.

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

IT>>Кстати, весь этот разговор не имел бы смысла, если бы не этот факт. Не исключено, что в скорости появятся клоны и усовершенсвтвования того же C#, именно по той причине, что можно сконцетрироваться только на языке и разрабатывать его в условиях уже готового и отлаженного окружения.

С>Я немного не понял. Здесь идёт обсуждение создания принципиально новой концепции языка или новой надстройки над новой, ещё не до конца развитой технолигией.

Говорил бы уже сразу "недоразвитой" зачем стесняться.
Т.е. по твоему все языки поддерживающие CLR это не языки, а надстройки? Очень интересно. По твоей логике, поддержка любым языком CLR тут же переводит его из категории "язык" в категорию "надстройка".

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


IT>Говорил бы уже сразу "недоразвитой" зачем стесняться.
IT>Т.е. по твоему все языки поддерживающие CLR это не языки, а надстройки? Очень интересно. По твоей логике, поддержка любым языком CLR тут же переводит его из категории "язык" в категорию "надстройка".

Ни в коем случае. Но пока что ни один из языков, поддерживающих CLR нельзя назвать принципиально новым.

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

IT>>Т.е. по твоему все языки поддерживающие CLR это не языки, а надстройки? Очень интересно. По твоей логике, поддержка любым языком CLR тут же переводит его из категории "язык" в категорию "надстройка".

С>Ни в коем случае. Но пока что ни один из языков, поддерживающих CLR нельзя назвать принципиально новым.

А их никто так и не называет. Речь о том, что как бы нов не был язык ему понадобится окружение, хотя бы для того чтобы сказать первое "Hello, world!". А следовательно это окружение необходимо будет разрабатывать вместе с языком. Кроме того необходимо будет реализовать генерацию нативного кода, хорошо бы сделать оптимизатор и т.д. CLR даёт это всё на халяву и можно сконцентрироваться собственно на самом языке. Вот и всё что я хотел сказать.

Угу... Хмм. Ага.

Теперь уже я буду выглядеть оглядывающимся на C++ & co, но мутные типы и объектность Python'а меня не привлекают. Какжется, Python только лишь объектный, а не объектно-ориентированный, или я устарел? В общем-то я говорил не о "фишках", а об использовании... ммм... о поддержке. Как там Бъерн говорил: "бывают языки, поддерживающие определенную парадигму". А бывает, что и нет.
Конечно же, большинство проектных решений можно реализовать при помощи наследования и кучи виртуальных функций, однако часто приходится ставить кучу невнятных скобок
((..)((((()..)....).), вызывая пару функций там, где обошлись бы и точкой (была б она перегружена).

Улучшения нужны, маленькие и большие. Любые, позволяющие ускорить процесс написания программ. То есть именно написания. Может будущее и за мышками + Drag&Drop, только не шибко верится, что это будет быстрее.

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

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

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

IT>...... CLR даёт это всё на халяву и можно сконцентрироваться собственно на самом языке. Вот и всё что я хотел сказать.

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

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

IT>>...... CLR даёт это всё на халяву и можно сконцентрироваться собственно на самом языке. Вот и всё что я хотел сказать.

С>В таком случае на халяву есть огромный выбор уже готовых языков. И можно сосредоточиться на написании програмных продуктов.

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

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


IT>Да и программных продуктов уже не мало, так что можно сконцентрироваться на их использовании

На новые програмные продукты спрос намного выше, чем на новые языки. Так что пока мы будем сидет и придумывать СамиНеЗнаемЧто, другие завоюют весь рынок програмных продуктов, а языки пусть Маэстро(MS) придумывает.

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

P>Угу... Хмм. Ага.

P>Теперь уже я буду выглядеть оглядывающимся на C++ & co, но мутные типы и объектность Python'а меня не привлекают. Какжется, Python только лишь объектный, а не объектно-ориентированный, или я устарел?

Устарел.

Прошу прощения за то, что оставил на некоторое время обсуждение.
Попрошу всех посмотреть, с чего все началось — http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&amp;id=1028039858&amp;n=3
Особенно мои посты (Igorek)
Там, где про конструкции восприятия, а также близость языка к прикладной области, машине, программисту одновременно.

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

.давайте по существу.

Меня просто бесит C++. Мрак. Еще больше бесят компилеры.
Кстати, тот пример, что я приводил в конфе "C/C++.Компиляторы" многими компилится, покуда все собрано в одном файле. Стоит только разнести на два и !

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

В случае отсутствия публичных членов, как предлагалось в форуме мастеров Дельфи, возникает необходимость описывать свойства. Наличие публичных членов действительно вызывает неприятное ощущение. Не всегда создаваемый проект является "вещью в себе", когда из конструкторских соображений можно сказать: "Если это поле будет приватным, то ничего не случится, поскольку мы намерено ничего не портим".

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

Встает вопрос: для чего чаще всего необходимо использовать свойства?

Ответ номер один: для предотвращения несанкционированной записи в поле.
Если мы, пытаясь реализовать сами свойства как можно эффективнее, будем заменять вызов функции на код ее тела, то мы не решим продлему косвенного доступа. Косвенный доступ — это прямо запись по указателю.
С одной стороны, можно окиваться: "мол, мы предоставляем средства для стректурирования, а не для предотвращения вредного использования", а про себя отложить эту проблему, пока в голову не придет приемлемое решение (C++).
С другой, можно изничтожить нафиг все указатели и их проявления. Но указатели — это язык машины, и, собственно, очень дешевая и понятная концепция связи, без которой очень неуютно. Неуютно не из-за невозможности писать *q++, а по причине обнищания возможностей. Тогда мы начинаем вводить кипу ключевых слов, вроде ref-out-of-sub, оставляя возможность косвенного связывания без обхода вызова свойтсва (C#).
Напрашиваемое решение — ключевое слово readonly, которое также есть в C# (там вообще много всего есть).
В этом случае мы просто запрещаем использовать присваивание (статическая проверка) или же записываем в тело объекта адрес виртуальной таблицы обработчиков свойств и в указателе(ссылке) явно указываем, что доступ к полю идет по свойству (ссылка гуляет по программе, непременно сохраняя свой флажок — все должен правильно откомпилить компилер, так чтобы дальше шла динамическая проверка).

При этом, опасность обхода функций для свойства (когда прямо пишут в поле) чаще всего связана с какими-то необходимыми побочными действиями, рассылкой сообщений и т.д. Можно сказать: "***, да это же дорого. А как же 'не пользую не плачу'!!! Да ну вас нафиг, я тут в переменную записал, а там шорох пошел на полсекунды!". А можно сказать: "Так и должно быть! В противном случае пришлось бы ручками прописать вызов этих самых функций".

Т.е. Ответ номер два: для слежением за изменением переменной, причем из нескольких мест.
В этом случае, простые свойства не работают, если мы используем чужую библиотеку. Если разработчик оказался предусмотрительным и позволяет подписаться на сообщение, рассылаемое его недосягаемым уже свойством, то все хорошо. Если нет — все плохо (Ну, почти все | хотя наследование тоже не поможет, если использовать нашего нового ребенка будет тоже библиотечный код, а свойство не виртуальное).

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

Вот таким путем.
Советы и пожелания кладите тут ниже.

Всех приславших мне письма касаьельно XASM прошу снова объявиться....
Edmond

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

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

Правильно, начинать надо с прагматики и только потом говорить о семантике и синтаксисе

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


IT>Т.е. можно говорить только о проблеме потребления ресурсов, но никак не о быстродействии. В конце концов оптимизаторы и для C# и для C++ писались одной и той же конторой
Не для Ц++, а для Вижуал Ц++...
есть реализации Ц++, которыые к Ц#и близко не стояли по быстродействию

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

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

а почему тока MS??? Borland тоже чаво-то умеет... да и SUN, близок к тому
так что давайте просто писать что-то на чем-то и тратить свободное время на разговоры в РСДН, а не на попывтки придумать "ват такую фитюльку" для того "чтобы они от зависти лопнули"

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

P>Конечно же, программируя на C++ я могу гордиться, мол моя программа будет даже на Sparc работать. Только будет это слишком самонадеяно, а самое главное: кто из нас Спарк хотя бы раз видел и трогал в живую?

Я трогал!!!
я на ем даже программировал... одно могу сказать: OpenGL тама и правда быстрый... а все остальное — сплошной отстой (я про скорость, правда у меня не самфый крутой Спарк был — всего лишь UltraStation 10 (512 RAM, а проц — не помню.. по моему 75, не уверен) так что вот )

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

H>Существует большое количество языков программирования, но наиболее популярны сейчас диалекты C/C++. Реально удобный язык, в меру переносимый, короче всем хорош. Даже UNIX на нем от и до написан. На каком еще языке есть реализованные операционные системы?

Вот только вчера прочел BYTE #3'2000 — обзор языков программирования.
Хотя общая идея там была "Си/Си++ сакс" — неважно, по сравнению с Фортом или Обероном. Но это не суть.

Любой язык, обладающий достаточной выразительностью, может послужить базисом для ОС.
Есть примеры систем на Форте (преимущественно — микроконтроллерные), Лиспе, Смолтоке (микроядро содержит форт-, лисп- или смолток-процессор, а все остальное — образ памяти).
Никлас Вирт экспериментировал с Паскалем (проект USCD Pascal, затем Modula, Component Pascal, Oberon). Все это доводилось до уровня операционной системы.

Кстати, вы не задумывались, почему в Windows 3.1 некоторые функции API имеют спецификацию PASCAL? Шютка.

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

IT>>Т.е. можно говорить только о проблеме потребления ресурсов, но никак не о быстродействии. В конце концов оптимизаторы и для C# и для C++ писались одной и той же конторой
HD>Не для Ц++, а для Вижуал Ц++...
HD>есть реализации Ц++, которыые к Ц#и близко не стояли по быстродействию

Глословный треп. Один из самых быстрых компиляторов VC7. Даже он не так далек от шарпа. А современем (когда у MS найдется время на вылизывание оптимизатора для .NET-рантайм и MS добавит в Шарп шаблоны) Шарп вооб может начать создавать самый быстрый код.

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

К>Кстати, вы не задумывались, почему в Windows 3.1 некоторые функции API имеют спецификацию PASCAL? Шютка.

Это не шутка. Первая версия виндов (вернее даже гуевой библиотеки) как раз на паскале и была.

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

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

IT>>>Т.е. можно говорить только о проблеме потребления ресурсов, но никак не о быстродействии. В конце концов оптимизаторы и для C# и для C++ писались одной и той же конторой
HD>>Не для Ц++, а для Вижуал Ц++...
HD>>есть реализации Ц++, которыые к Ц#и близко не стояли по быстродействию

VD>Глословный треп. Один из самых быстрых компиляторов VC7. Даже он не так далек от шарпа. А современем (когда у MS найдется время на вылизывание оптимизатора для .NET-рантайм и MS добавит в Шарп шаблоны) Шарп вооб может начать создавать самый быстрый код.

Я же не говорил, что все варианты Ц++ медленнее Ц# по результатам ВСЕХ тестов здесь

Автор(ы): Владислав Чистяков

и следующих статьях, мы видим, что bcb проигрывает Ц# в тесте сложения строк в 10 (!!!!!) раз...
я хотел сказать, всего лишь, что не стоит кричать, что Ц# намного медленнее, чем Ц++. на это можно лишь возразить, что все зависит от задачи.
Можно на ассемблере написать реализацию кода, которая будет работать медленнее, чем то же самое, написаное на VB, даже при отсутствии оптимизатора в последнем — вопрос реализации.
А уж Ц# написан весьма неплохо и производительность у него неплохая (да, согласен, грузится медленно, но попробуйте выкинуть все из ЕХЕ в ДЛЛ так, чтобы Ц++ код был того же размера — и поглядим, как долго он будет подниматься и устанавливать все связи (если они не статически линкуются)
так что, это не было наездом на Ц++ — это были слолва в пользу Ц#

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

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

К>>Кстати, вы не задумывались, почему в Windows 3.1 некоторые функции API имеют спецификацию PASCAL? Шютка.

VD>Это не шутка. Первая версия виндов (вернее даже гуевой библиотеки) как раз на паскале и была.

самое забавное, что по умолчанию считается, что надо использовать паскалевский вызов для функций, которые экспортируются из DLL (pascal) правда сейчас его заменили на stdcall, но, блин, мы же все помним, что это — паскальный вызов
и в старых компиляторах заголовки были типа BOOL PASCAL dgflsdh(ssdkfh inin, ufbeub rfer, eife *dfef);
так что действительно не щютка

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

К>>>Кстати, вы не задумывались, почему в Windows 3.1 некоторые функции API имеют спецификацию PASCAL? Шютка.

VD>>Это не шутка. Первая версия виндов (вернее даже гуевой библиотеки) как раз на паскале и была.

HD>самое забавное, что по умолчанию считается, что надо использовать паскалевский вызов для функций, которые экспортируются из DLL (pascal) правда сейчас его заменили на stdcall, но, блин, мы же все помним, что это — паскальный вызов
HD>и в старых компиляторах заголовки были типа BOOL PASCAL dgflsdh(ssdkfh inin, ufbeub rfer, eife *dfef);
HD>так что действительно не щютка

От "паскалевских" stdcall'ов меньше код раздувается (что когда-то было критично), только и всего. Потому они в системных библиотеках и юзаются.

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

К>>Кстати, вы не задумывались, почему в Windows 3.1 некоторые функции API имеют спецификацию PASCAL? Шютка.

VD>Это не шутка. Первая версия виндов (вернее даже гуевой библиотеки) как раз на паскале и была.

Во. Еще один человек это утверждает. Откуда дровишки, где-нибудь в сети тому подтверждение осталось?

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

статьях, мы видим, что bcb проигрывает Ц# в тесте сложения строк в 10 (!!!!!) раз...
HD>я хотел сказать, всего лишь, что не стоит кричать, что Ц# намного медленнее, чем Ц++. на это можно лишь возразить, что все зависит от задачи.

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

Вот возьмем например простейший вариант: сортировка массива. Там присутствует большое количество обращение к элементам массива. C++ никак не контролирует программиста, обратился за границу — undefined behavior. Тогда как C# и Java не могут себе это позволить, и поэтому каждое обращение внутри имеет проверку на границы массива(на верхнюю и нижнюю). В результате получается что обращение к элементу массива будет в 3 раза медленнее. Вот тебе и замедление. Сортировка в отличие от поиска простых чисел используется почти везде.

И объясните мне pls как ваш C# собирается догонять C++ в данном случае.

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

S>Во. Еще один человек это утверждает. Откуда дровишки, где-нибудь в сети тому подтверждение осталось?

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

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

HD>так что, это не было наездом на Ц++ — это были слолва в пользу Ц#

Ну, на С++ тоже наезжать не стоит. Ты ведь сам сказал, что все зависит от задачи... Я бы перефразировал: от ее реализации.

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

A>Видишь ли все ваши тесты они неестественные, Java ищет простые числа с такой же скоростью как и C++ ну и что, зато она сильно отстает в алгоритмах которые требуют минимального пробега по памяти, а таких извини большинство.

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

A>Вот возьмем например простейший вариант: сортировка массива. Там присутствует большое количество обращение к элементам массива.

Скорее всего отставание объясняется слишком тупым алгоритмом проверки выхода за пределы массива. Это исправимо (как доказал тот же Шарп). Но в текущей реализации не исправленно.


HD>C++ никак не контролирует программиста, обратился за границу — undefined behavior.

В VC7 проверка границ массива тоже встроена, но опционально. В шапре тоже есть ансэйф-режим в котором нет контроля, но и в нем Шарп отстал от С++. Так что видимо дело в оптимизации.

HD>Тогда как C# и Java не могут себе это позволить

Шарп может.

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

Заметь результат сортировки Шарпа даже в обычном режиме очень даже ничего. Можешь сравнить их с результатом qsort из CRT. Уверяю тебя что qsort проиграет (по крайней мере в реализации MS из VC6).

A>И объясните мне pls как ваш C# собирается догонять C++ в данном случае.

Элементарно. Оптимизируют оптимизатор. Тот начнет реально выдавать инструкции для новых процесоров и С++ (вернее кодогенерация в стиле обычного С++) будет в анусе.

Основные проблемы Шарпа не в проверках границ массивов, а в отсуствии шаблонов. Это приводит к тому что любой общий алгоритм реализуется на виртуальных методах. А это тормоза (хотя и не критичные). Кстити, в С (который и сейчас является эталоном по скорости программ) полиморфизм достигался тоже за счет (псевдо-) виртуальных вызовов. Та же qsort тому доказательство. Она сильно проигрывает в скорости из-за того, что приходится делать вызов по адресу и передавать в функцию сравнения указатели.

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

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

HD>>так что, это не было наездом на Ц++ — это были слолва в пользу Ц#

VD>Ну, на С++ тоже наезжать не стоит. Ты ведь сам сказал, что все зависит от задачи... Я бы перефразировал: от ее реализации.

Как уже обсуждалось в флейме о Дельфи и от задачи — тоже... когда нужно написать программу, которая выводит на экран надпись "Hallo World!" — лучший выход это VB/Delphi/C#, т.е. компоненто-ориентированые системы с однопроходным (это важно !) компилятором (правда, про Ц# не уверен, но исходя из отсутствия макросов можно предположить ). Когда нужно написать программу под Intel x86, которая будет ОЧЕНЬ быстро искать прямым перебором (ну данные так устроены) данные в массиве int'ов — лучший выход — ассемблер, благо там для этого команда специальная есть. Так что от задачи тоже многое зависит.

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

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


IO>Всем: машин много разных, но тем не менее у всех стоит двигатель внутреннего сгорания (и на легковых и на грузовых и т.д.).

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

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

IO>Ваши мнения?

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

(С) Ленивый програмист Петька
ICQ: 70064374

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

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

IO>>Ваши мнения?

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

А я хочу чтобы он при этом еще выполнял то что я хочу, а не то что я написал

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

HD>>Тогда как C# и Java не могут себе это позволить

VD>Шарп может.

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

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

IO>>Всем: машин много разных, но тем не менее у всех стоит двигатель внутреннего сгорания (и на легковых и на грузовых и т.д.).

U>Не обязательно, еще ставится дизель.

А что, двигатель Дизеля теперь стал двигателем внешнего сгорания?

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

A>А я хочу чтобы он при этом еще выполнял то что я хочу, а не то что я написал
... или подумал

А я хочу, чтобы он при этом еще выполнял то, чего хочет заказчик, а не чего хочу я.

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

A>Я в принципе верю что при пробеге по массиву оптимизатор
A>может заметить что индекс и так никогда за массив не вылезит,
A>но в более менее сложном случае он разобраться не сможет

Если что есть ансэйф-код. Там ты можешь хоть по памяти кувалдой. Так что Шарп из любого положения может.

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

HD>Когда нужно написать программу под Intel x86, которая будет ОЧЕНЬ быстро искать прямым перебором (ну данные так устроены) данные в массиве int'ов — лучший выход — ассемблер

Бред натуральный. Моежт данные отсорировать и хоть бинарным поиском воспользоваться? А там глядишь и VBScript в 100 раз шустрее асм-а окажетя.

HD>, благо там для этого команда специальная есть. Так что от задачи тоже многое зависит.

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

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

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

A>>А я хочу чтобы он при этом еще выполнял то что я хочу, а не то что я написал
Z>... или подумал

Z>А я хочу, чтобы он при этом еще выполнял то, чего хочет заказчик, а не чего хочу я.

Нет это в корне не правильный подход! Так ты и без работы остаться можешь

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

A>Нет это в корне неправильный подход! Так ты и без работы остаться можешь

А это будет приватный проект

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

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

Объясни мне pls подробнее про unsafe код в C# что это вообще такое и как это согласуется с IL. Или линк кинь.

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

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

IO>>>Всем: машин много разных, но тем не менее у всех стоит двигатель внутреннего сгорания (и на легковых и на грузовых и т.д.).

U>>Не обязательно, еще ставится дизель.

Z>А что, двигатель Дизеля теперь стал двигателем внешнего сгорания?

Турбина тоже не внешного, давай те для общности и ее назовем двигателем внутренного сгорания

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

IO>>>>Всем: машин много разных, но тем не менее у всех стоит двигатель внутреннего сгорания (и на легковых и на грузовых и т.д.).

U>>>Не обязательно, еще ставится дизель.

Z>>А что, двигатель Дизеля теперь стал двигателем внешнего сгорания?

U>Турбина тоже не внешного, давай те для общности и ее назовем двигателем внутренного сгорания

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

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

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

HD>>Когда нужно написать программу под Intel x86, которая будет ОЧЕНЬ быстро искать прямым перебором (ну данные так устроены) данные в массиве int'ов — лучший выход — ассемблер

VD>Бред натуральный. Моежт данные отсорировать и хоть бинарным поиском воспользоваться? А там глядишь и VBScript в 100 раз шустрее асм-а окажетя.
Ешшо раз внимательно прочитай предположение — ДАННЫЕ ТАК УСТРОЕНЫ. Есть такие задачи... есть...
когда тебе нужно искать в ЧУЖОЙ памяти некоторые данные, причем память достаточно часто изменяется — единственный выход — это

LOCK REP SCASD

И никакой Ц тебе не даст такой возможности А работать это будет гораздо быстрее, чем реализация перебора на Ц++ с использованием циклов (ибо начиная с 5х86 перебор одного элемента цепочки занимает не больше одного такта процессора/памяти (зависит от того, влезли ли данные в кэш).
VD>Переборы и циклы уже сто раз оптимизировалис компиляторами. Серьезного выигрыша (в разы) получить нельзя. Сегданя даже базовые алгоритмы на асм-е не пишут (бесполезно), а уж кусти прикладной логики на асм-е могут писать только его истенные ценители и в нерабочее время.

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

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

Z>>>А что, двигатель Дизеля теперь стал двигателем внешнего сгорания?

U>>Турбина тоже не внешного, давай те для общности и ее назовем двигателем внутренного сгорания

А>Дык, дизельный двигатель наряду с карбюраторным являются двигателями внутреннего сгорания.

Для общности определим так: ДВС — это тепловой двигатель, у которого рабочее тело и нагреватель суть одно, а рабочий объем ограничен.
Сюда включаются двигатели Дизеля и Отто (в первом поджиг — от адиабатического нагрева, во втором — от воспламенителя — искровой или калильной свечи), газотурбинные.

Реактивные двигатели (в том числе газотурбинные) отличаются способом отбора мощности.

Мощно задвинул?

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

К>Мощно задвинул?

Да... мусор отдыхает.

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

HD>

HD>LOCK REP SCASD
HD>

HD>И никакой Ц тебе не даст такой возможности

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

HD>А работать это будет гораздо быстрее

Ой ли? И часто ли встречаются столь маштабные и тупые переборы?

VD>>Переборы и циклы уже сто раз оптимизировалис компиляторами. Серьезного выигрыша (в разы) получить нельзя. Сегданя даже базовые алгоритмы на асм-е не пишут (бесполезно), а уж кусти прикладной логики на асм-е могут писать только его истенные ценители и в нерабочее время.

HD>Начет бесполезно — ты не прав. Есть задачи, которые на АСМ решаются элегантнее и быстрее (выполнение). Вот если бы процессор сам исполнял и оптимизировал Ц код — вполне возможно, что он был бы быстрее, а так — не понятно . Хорошая реализация на ассемблере никогда не будет медленнее, чем реализация на Ц/Паскале и прочих языках программирования.

Ну, вроде выше я уже все скзал...

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

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

A>Объясни мне pls подробнее про unsafe код в C# что это вообще такое и как это согласуется с IL. Или линк кинь.

IL — это ассемблер для вымышленного процессора который не имеет регистров и все операции выполняет над операндами помещенными в стек (тоже вымышленный). Перед исполнением этот вымышленный код компилируется в код совместимых с имеющимся процессором.

IL по своим возможностям не отличается от ассемблера. Ну разве что нельзя вызывать прерываний и писать в порты.

Ансэйф код в Шарпе — это возможность наплевать на GC с безопастностью и взять управление на себя (скатившись до уровня С). В Шустрике

Автор(ы): Владислав Чистяков

продемонстрирован вариант применения ансэйфа в Шарпе (ищи по словам unsafe и fixed).

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

VD>Ансэйф код в Шарпе — это возможность наплевать на GC с безопастностью и взять управление на себя (скатившись до уровня С). В Шустрике

Автор(ы): Владислав Чистяков

продемонстрирован вариант применения ансэйфа в Шарпе (ищи по словам unsafe и fixed).

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

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

VD>>Ансэйф код в Шарпе — это возможность наплевать на GC с безопастностью и взять управление на себя (скатившись до уровня С). В Шустрике

Автор(ы): Владислав Чистяков

продемонстрирован вариант применения ансэйфа в Шарпе (ищи по словам unsafe и fixed).

A>А ну понятно, здесь кстати было невооруженным взглядом видно что все находится в пределах массива, цикл то по нему. Более интересно было бы с нетривиальным алгоритмом, например qsort-ом там оптимизатор вряд ли сможет сделать предположения.

Ну если вниательно посмотреть тесты, то можно обнаружить там тот самый алгоритс быстрой сортировки (qsort). На моей машине (Атлон 2100+) в ансэйф-режиме (при работе с указателями, т.е. без контроля границ массивов) 7.51 сек. и в обычном режиме (с контролем выхода за границу) 7.63 сек. В общем в реальных приложениях можно смело плевать на контроль границ массивов. Правда VC7 на том же тесте показывает 6.30 сек. Но это похоже из-за лучшей оптимизации.

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

VD>Ну если вниательно посмотреть тесты, то можно обнаружить там тот самый алгоритс быстрой сортировки (qsort). На моей машине (Атлон 2100+) в ансэйф-режиме (при работе с указателями, т.е. без контроля границ массивов) 7.51 сек. и в обычном режиме (с контролем выхода за границу) 7.63 сек. В общем в реальных приложениях можно смело плевать на контроль границ массивов. Правда VC7 на том же тесте показывает 6.30 сек. Но это похоже из-за лучшей оптимизации.

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

P>Конечно же, программируя на C++ я могу гордиться, мол моя программа будет даже на Sparc работать. Только будет это слишком самонадеяно, а самое главное: кто из нас Спарк хотя бы раз видел и трогал в живую?

Я. Скажу больше: "Программа на C++ && STL без проблемм работает и на WinIntel и на SunSparc"

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

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

И еще: существует же псевдокод, который используется в книгах по программимрованию. И он реализуем на любом алгоритмическом языке.
Я не говорю, что это будет легко, или что это вообще 100% возможно, но попробовать стоит (в свободное время)

А еще лучше обсудить для начала сами парадигмы.

Эстафета — знатокам.

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

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

Вот этот набор мне здорово напомнил Forth

P.S. Может кому будет интересен наш c:)

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

Моё мнение таково, что вы знаете слишком мало языков, чтобы осознать всю бессмысленность вашей идеи.
Неужели вы думете слелать язык с простым синтаксисом (бейсик), полной поддержкой ООП(Си++), возможности низкоуровневых операций (асм), с мощными регулярными выражениями (Перл), переносимый (Java) и прочее прочее (Пролог, Лисп и пр.).

Тут языки приведены примерно.

Это была бы кофеварка совмещённая с профессиональной звуковой студией и унитазом.

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

Здравствуйте Reinhard, Вы писали:
R>Моё мнение таково, что вы знаете слишком мало языков, чтобы осознать всю бессмысленность вашей идеи.
Вполне возможно (даже скорее всего).

R>Неужели вы думете слелать язык с простым синтаксисом (бейсик), полной поддержкой ООП(Си++), возможности низкоуровневых операций (асм), с мощными регулярными выражениями (Перл), переносимый (Java) и прочее прочее (Пролог, Лисп и пр.).
А как вам язык с неопределенным синтаксисом? Т.е. сам синтаксис для компилятора неизвестен. Синтаксические модули просто подключаются и вы можете пользоваться удобной Вам формой (ведь в конечном итоге получиться все равно машинный код). Идея в том, что не надо ничего учить. Хотите свой диалект — пишите синтаксис, подключайте и вперед. И любой другой прочитает ваш код в своем диалекте.

Простите, если нехотя что-то глупое прозвучало.

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

IO>А как вам язык с неопределенным синтаксисом? Т.е. сам синтаксис для компилятора неизвестен. Синтаксические модули просто подключаются и вы можете пользоваться удобной Вам формой (ведь в конечном итоге получиться все равно машинный код). Идея в том, что не надо ничего учить. Хотите свой диалект — пишите синтаксис, подключайте и вперед. И любой другой прочитает ваш код в своем диалекте.

Есть такая буква! Можно посмотреть здесь. Раздел 3.2. Правда там говорится, что сложность компилятора возрастает настотько, что язык общего назначения не представляется возможным построить... Плюс надо вооружиться нетривиальной теорией. А так — дело благое, так что флаг в руки.

IO>А как вам язык с неопределенным синтаксисом? Т.е. сам синтаксис для компилятора неизвестен. Синтаксические модули просто подключаются и вы можете пользоваться удобной Вам формой (ведь в конечном итоге получиться все равно машинный код). Идея в том, что не надо ничего учить. Хотите свой диалект — пишите синтаксис, подключайте и вперед. И любой другой прочитает ваш код в своем диалекте.

Эдакий XML для программера.
Тогда получается как бы язык для создания языков. Только это скорее другая задача.
Да и наверняка на этом нельзя будет написать ни одной программы, а надо будет сначала
синтаксис задать, а потом на этом субъязыке уже писать.
Это автоматически породит бесчисленное множество синтаксисов, по определению не совместимых
друг с другом. Один похож на Си++, другой — ПОЧТИ такой же, но бесплатный проект, третий
— тоже Си++, но мощный и глючной. Это только в одном напроавлении. Вокруг каждого создадутся
группки последователей, а синтаксис станет как бы новым языком, возможно со
специализированными компилерами.

В жизни уже есть пример — XML. На его основе можно делать синтаксисы. Только это порождает
новые языки, а не делает один универсальный.

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

Только спорный даже этот вопрос, потому как компилятор умеющий делать
только debug-программы — неоптимальный инструмент.
Я имею в виду язык без данной фичи (Си++ MS Visual), но с довесой
для этапа разработки типа NuMega BoundChecker.

http://cog.cognitivity.com/perl6/
оттуда многое можно почерпнуть

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

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

IO>>Ваши мнения?

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

А>(С) Ленивый програмист Петька
А>ICQ: 70064374

Ой, Петька, не надо! А то если он выполнит то, что ты пишешь, очень беда может большая быть. Потому, что упомянутый русский например значительно сложнее, чем любой из существующих языков программирования. Вона, в форуме, столько программеров толковых, а москальску мову не розумеют ни черта. И в твоей этой фразе ошибок -[ правила форума запрещают обсуждение грамотности участников ]. Так что не надо такого языка программирования.

Здравствуйте, IO,
Что то в этом форуме много пессимистов Может они в чем то и правы, но суть
не в этом.
Я очень давно интересуюсь технологией компиляции и должен сказать, что создать действительно хороший язык, удавалось только избранным. НО если вы готовы занятся
разработкой компилятора, хотя бы с очень простым синтаксисом (для начала), то эта
затея оправдывает себя по двум причинам:
Во первых на этом можно неплохо заработать, но это не главное, главное то, что
при разработке компилятора круг возникающих проблем очень велик, и поэтому как
программист вы будете развиватся, а это не мало важно.
Короче я ЗА! У меня эта идея уже давно была, вот только в одиночку не справится.
Если, что я оставляю адрес d_den@mail.ru

Получите ИМХО, раз просили.
Оно такое: языков должно быть два:
1-й: для развития системы.
2-й: для собственно программы(UI, главным образом).
Никоим образом не претендую на "САМОЕ ПРАВИЛЬНОЕ имхо". Наоборот, хотелось бы услышать (увидеть) другие мысли...

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

Меня всегда интересовало кто возмется за ответственность "привязонности" (понятие общее но под какую платфоруму будет заточен — я бы не взял на себя ответственость — хотя я и LOL).

А теперь мое личное мнение (ногами можете бить если — попадете (кто был на встрече RSDN поймет )).

Сейчас надо разрабатывать языки с привязкой к конкреной OC — так как получим максимальную производительность (если разработчики компилятора(интерпритатора) ерундой не занимались).

А мысли котрые проскакивали уже дано насчет своей OC — я поддержу — но пока только в проекте — потому что не чуствую в себе тех сил которые должны быть в человеке при разработке OC — (я еще очень сильно хромаю в ассемблере — дает знать — 54 летняя задержка в технологиях — я думаю через год можно поднять тему снова).

Если ее раньше не поднимут — я ее поддержу — возможными силами и средствами (связями — тоже )

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

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

IO>Ваши мнения?

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

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

IO>Ваши мнения?

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

Язык программирования десятого уровня С**.
Ламер и Гуру:
Л: Я тут программу написал, не работает...
Г: Покажи.
Л: "Хочу базу данных;"
Г: Эх ты, ламер... Надо так: "Хочу базу данных(чтоб работала);"

You will always get what you always got
  If you always do  what you always did

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

IO>Ваши мнения?

Не хватает целой кучи макро-удобств:

1)
__FILE__
__LINE__

Этого слишком мало! Хочу __TEXT__, __METHODNAME__, __METHODTEXT__.

2) Нельзя нормально наследовать макросы.
Например, сборка Release не содержит в себе #define new, сборка Debug содержит #define new DEBUG_NEW
И всё!
А нет бы добавить сборку Debug_TestMemoryOptimize:
#ifdefdefineandinherit new MYDEBUG_NEW
а компилятор подставлял бы вместо new сначала стандартный дебужный new, а потом мой.

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

Вообще макроподстановки — целая песнЯ, об удобстве их использования мало кто думает, а ведь это — хороший инструмент.