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

VD>... все ползут в этом направлении. Питон снизу на пузе. Дотнет сбоку на мешке с баксами. Немеле и Хаскель сверху на научном багаже. ...

А C++?

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

VD>>... все ползут в этом направлении. Питон снизу на пузе. Дотнет сбоку на мешке с баксами. Немеле и Хаскель сверху на научном багаже. ...

I>А C++?

C++ — труп. Он никуда не ползёт.

konsoletyper wrote:
> VD>>... все ползут в этом направлении. Питон снизу на пузе. Дотнет сбоку
> на мешке с баксами. Немеле и Хаскель сверху на научном багаже. ...
> I>А C++?
> C++ — труп. Он никуда не ползёт.
Куда же он денется, жив еще курилка (не путать с
http://rsdn.ru/Users/Profile.aspx?uid=1546 !).

Сейчас ползет в сторону hardcore-оптимизаций (типа move constructors,
управления aliasing'ом) и более мощного метапрограммирования.

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

VD>>... все ползут в этом направлении. Питон снизу на пузе. Дотнет сбоку на мешке с баксами. Немеле и Хаскель сверху на научном багаже. ...

I>А C++?

Он ползет в известном направлении... в магилу.

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


>> C++ — труп. Он никуда не ползёт.
C>Куда же он денется, жив еще курилка (не путать с
C>http://rsdn.ru/Users/Profile.aspx?uid=1546 !).

Курилка то жив (не путатьс с http://en.wikipedia.org/wiki/C%2B%2B) .

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

C>Я прошу прощения за оффтоп... Не первый раз встречаюсь с фразой "утиная типизация". Это что за зверь такой?

Как дотнетчик дотнетчику

interface IMyInterface
{
  void Foo();
  void Bar(int i);
}

class MyClass1 // наследования от интерфейса IMyInterface нет
{
  void Foo() {}
  void Bar(int i) {}
}

class MyClass2 // наследования от интерфейса IMyInterface нет
{
  void Foo() {}
  void Bar(int i, int j) {}
}

static class Test
{
  static void Method(IMyInterface mi)
  {
  }
}

void Main()
{
  Test.Method(new MyClass1()); // OK
  Test.Method(new MyClass2()); // Fail, сигнатуры методов не удовлетворяют интерфейс IMyInterface
}

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

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

FR>>Мне там интересным показалась не само введение статики, а именно расуждения про типы.

VD>Тогда очень советую почитать про классы типов Хаскеля. Там все на довольно высоком научном уровне спроектированно. Плюс это уже работает, т.е. гарантированно корректно и не противоречиво.


Посмотрим. Хотя смутно помню что читал по диагонали.


FR>>А по поводу статики для питона необходимости нет, но и мешать тоже не будет.

VD>Аднако автор Питона с тобой не вполне согласен. И я его всецело поддерживаю.

Вполне он со мной согласен, сейчас в планах на питон 3.0 введение опциональной статической типизации стоит с пометкой "может быть"

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

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

FR>>Нет совпадение сигнатур методов не нужно, нужно чтобы объект содержал все сигнатуры которые есть в интерфейсе, то есть то же "утиное" сопоставление.

VD>Это и есть совпадение сигнатур. Блин, поспорить что ли охота?

Нет спорить некогда.


FR>>Скорее как в С++
FR>>Но это только для параметризировнных типов.

VD>Тебя так и прет поспорить ни о чем. Адреналину что ли нехватает? Какая разница С++ или Шарп? Речь идет о явном задании параметров типов. В отлчии от этого подхода ОКамл и Хаскель подразумевают что все типы бобщены по умолчанию и что переменные типы как бы есть априори. Выражаясь наукобразным языком — все типы стоят под квантором всеобщности.

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

VD>О С++ же я не упоминал по ричини того, что шаблоны в нем вещь чисто текстуальная. В рантайме их нет. А в Питоне явно говорится о интерфейсах аналогичных донтентым — существующим в рантайме. Ну, да это уже дело десятое. Нет никакого желания втягиваться в дискуссию С++ вс. Шарп.

FR>>Так это и есть основная фишка.

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

Я это не отрицаю, но это не так интересно для меня сейчас.

VD>Ты во всю плевался в Boo, а когда автор Питона предложил по сути аналогичные вещи ты вдруг нашел это предложение интересным, но усмотер в нем все что угодно, но не суть.

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

VD>ЗЫ

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

С этим в общем согласен.

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


VD>Ты невнимательно читал и не уловил суть. Это всего лишь средство более гибко оформить пре-условия. Там есть такое замечание:

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

FR>>Окамл насколько я помню через ж... может решать эту проблему.

VD>Ты не правильно понимаешь. У ОКамла есть три проблемы:
VD>1. Все идентификаторы должны быть уникальны или полностью квалифицироваться именем модуля. То есть ты не можешь создать два типа или две функции с одинаковыми именами.
VD>2. В следствии п. 1 и карринга невозможна перегрузка функций.
VD>3. Недопустимы неявные приведения типов.
VD>4. Имеется дурацкий запрет на upcast.
VD>5. Арифмитические операторы недопускают пергрузку. Для флоатов используется одтедьный оператор.

Вот 3. 4. 5. нормально нужно разрешить, и обсудалось именно это.

VD>В остальном язык более чем полноценнен. Все ограничения вызваны особенностями алгоритма вывода типов для системы тпов Хиндли-Миллера.

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

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

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

VD>>>Мне кажется, что ты хочешь видеть то, чего нет в этих статьях и не хочешь то, что там есть.

FR>>Мне тоже самое кажется насчет тебя

VD>Возможно, возможно... что статья не про то как к Питону статическую типизацию приделать, а про проблемы этой самой статической типизации. Значит я не уловил. Тебе виднее.

Конечно

FR>>Не понял какие цитаты?

VD>

Ну и кроме того обозначены и некторые проблемы которые например в том же окамле (а он типизирован по второй схеме) не разрешены.

VD>Твои слова? Ну, вот и приведи цитаты из этих статей где автор говорил о проблемах ОКамла.

Это проблемы не только Окамла, просто там они достаточно ярко проявлены. Почитай снова тему все это уже обсудили.

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

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

У каждого языка свои заскоки и фичи, питон в этом не исключение

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

К>А нет чего-нибудь серьёзного под рукой на эту тему?

К сожалению, нет.

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

FR>Конечно не конфликтует потому что в этих языка уже тип != класс.

Это ты уже сам придумал. На самом деле две эти вещи друг от друга вообще не зависят.

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

K>C++ — труп. Он никуда не ползёт.

Здесь отсутствует очень жирное ИМХО.

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

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

VD>>>... все ползут в этом направлении. Питон снизу на пузе. Дотнет сбоку на мешке с баксами. Немеле и Хаскель сверху на научном багаже. ...

I>>А C++?

K>C++ — труп. Он никуда не ползёт.

Либо пиши ИМХО, либо обоснуй... Честно говоря я не понимаю критериев по которым можно сказать, что некоторый язык умирает за исключением оттока разработчиков и снижение абсолютной доли рынка. Пока этого не видно.

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

K>>C++ — труп. Он никуда не ползёт.

L_S>Либо пиши ИМХО, либо обоснуй... Честно говоря я не понимаю критериев по которым можно сказать, что некоторый язык умирает за исключением оттока разработчиков и снижение абсолютной доли рынка. Пока этого не видно.

А вот я вижу. Прикладное ПО (за исключением игр) уже давно переходит на Java и .NET. Есть особые ситуации — графические библиотеки, игры, ОС и т.д. Но вот игры со временем будут переходить на managed-среды (и не надо отпираться, когда-то так же звучали "со временем игры будут писать для Windows). ОС, может быть (судя по экспериментам с Singularity). Вообще, думаю, разработчики в будущем осознают преимущество managed-сред и всяческие "числодробильные" куски программ будут всё больше уходить в сторону специфического ассемблера, а высокоуровневые части будут писать на Java/.Net. Причём хорошо, если в этом поспособствую Sun и MS и максимально упростят interop (хотя и сейчас всё очень просто).

C++ не развивается не только в этом смысле. Сейчас есть тенденция сдвига к ФП (вон даже MS начали ворочиться). В С++ если и есть ФП, то на уровне метапрограммирования. Что уж говорить о таких давно освоенных вещах, как, например GC, который так и не добавили в C++? Все добавления, которые в нём есть — это робкие попытки залатать те дырки, которые возникли в нём давно из-за неправильного дизайна, сохранив при этом совместимость. Единственное, что заслуживает внимания — это развитие метапрограммирования, но без всего остального оно того стоит?

Для C++ невозможно сделать хорошей IDE. Для C++ невозмножно написать полноценный парсер. C++ медленно компилируется. Для C++ есть куча костылей, которые так и не заменят чем-нибудь более удачным, например, чтобы решить все проблемы с иерархией include'ов, до сих пор поступают так:

#ifndef _MODULE_NAME
#define _MODULE_NAME

...

#endif

несмотря на всю кривизну такого подхода.

C++ держится за прошлое. Его мог бы спасти отказ от совместимости с C 30-летней давности, но тогда, возможно, это был бы не C++.

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

В общем, если что-то не очевидно сейчас, то это не значит, что не назрели тенденции. Язык C++ сделал когда прорыв в мэйнстриме, многому нас научил, многое сделал. Но теперь он уже отжил своё.

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

L_S>Либо пиши ИМХО, либо обоснуй... Честно говоря я не понимаю критериев по которым можно сказать, что некоторый язык умирает за исключением оттока разработчиков и снижение абсолютной доли рынка. Пока этого не видно.

Когда программисты и проекты начнут уходить с С++ массово, то это будет уже не смерть. Это будет разложение.

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

VD>Скажу больше. В обоих статьях я заметил исключительно сожаления о том, что Питон не имеет возможности статически типизировать код и идеи о том, как прикрутить статическую типизацию к Питону.

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

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

FR>Да те же самые про которые пишет выше eao197 и которые затронуты у ван Россума, и нерешение которых в окамле привело к уродцам типа '.+'

Если ты говоришь о перегрузке операторов, то ее отсутствие вызвано совсем другими причнами, которые к типизации не имеют никакого отношения. Или ты что-то другое имел в виду?

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

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

K>>>C++ — труп. Он никуда не ползёт.

L_S>>Либо пиши ИМХО, либо обоснуй... Честно говоря я не понимаю критериев по которым можно сказать, что некоторый язык умирает за исключением оттока разработчиков и снижение абсолютной доли рынка. Пока этого не видно.

K>А вот я вижу. Прикладное ПО (за исключением игр) уже давно переходит на Java и .NET. Есть особые ситуации — графические библиотеки, игры, ОС и т.д. Но вот игры со временем будут переходить на managed-среды (и не надо отпираться, когда-то так же звучали "со временем игры будут писать для Windows). ОС, может быть (судя по экспериментам с Singularity). Вообще, думаю, разработчики в будущем осознают преимущество managed-сред и всяческие "числодробильные" куски программ будут всё больше уходить в сторону специфического ассемблера, а высокоуровневые части будут писать на Java/.Net. Причём хорошо, если в этом поспособствую Sun и MS и максимально упростят interop (хотя и сейчас всё очень просто).

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

K>C++ не развивается не только в этом смысле. Сейчас есть тенденция сдвига к ФП (вон даже MS начали ворочиться). В С++ если и есть ФП, то на уровне метапрограммирования. Что уж говорить о таких давно освоенных вещах, как, например GC, который так и не добавили в C++? Все добавления, которые в нём есть — это робкие попытки залатать те дырки, которые возникли в нём давно из-за неправильного дизайна, сохранив при этом совместимость. Единственное, что заслуживает внимания — это развитие метапрограммирования, но без всего остального оно того стоит?
Вот все говорят про правильный и неправильный дизайн забывая о том, что задача языка не быть красивым, а быть функциональным. Т.е. идея не в том, что бы писать абсолютно безопасные программы, а что бы писать нужные программы. Вообще я смотрю на разные языки и у всех свои недостатки, просто некоторые языки развиваются и со временем превращаются в фичепомойку, которую затем зачем то называют неправильным дизайном, а другие языки в свою очередь отстаивают определенные позиции и с академической точки зрения имеют мало недостатков, но не применяются ибо для того, что бы их применять на промышленном уровне нужны высококлассные специалисты и до кучи не все на них можно сделать. Примеры приводить не буду ибо начнется холи вар ИМХО всем не угодишь по части фич

K>Для C++ невозможно сделать хорошей IDE. Для C++ невозмножно написать полноценный парсер. C++ медленно компилируется. Для C++ есть куча костылей, которые так и не заменят чем-нибудь более удачным, например, чтобы решить все проблемы с иерархией include'ов, до сих пор поступают так:

K>

K>#ifndef _MODULE_NAME
K>#define _MODULE_NAME

K>...

K>#endif
K>

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

K>C++ держится за прошлое. Его мог бы спасти отказ от совместимости с C 30-летней давности, но тогда, возможно, это был бы не C++.

K>Всё будущее, которое очевидно для C++ — уход в узкую нишу написания чего-то низкоуровневого. Причём, возможно, что его и оттуда вытеснит какой-нибудь язык, более специализированный, потому гораздо более удобный для решения конкретного круга задач.
Ладно тебе — какая уж тут узкая ниша. Ну вот например для встроенных систем пока нету тенденций к переходу на другие языки, а это отнюдь не узкая ниша и деньги тут крутятся очень большие. Затем всяческая цифровая обработка, драйвера, коммуникационное ПО, анализаторы сигналов и т.п. Я бы сказал, что .Net займет свою узкую нишу для создания бизнес приложений и автоматизации нежели С++

K>В общем, если что-то не очевидно сейчас, то это не значит, что не назрели тенденции. Язык C++ сделал когда прорыв в мэйнстриме, многому нас научил, многое сделал. Но теперь он уже отжил своё.
Просто ты наверное устал от С++ и тебе хочется чего то нового, но это не значит, что язык свое отжил.

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

<...попытки мерять язык с более чем 20-ти летней историей мерками сегодняшнего дня матерно поскипаны...>

K>В общем, если что-то не очевидно сейчас, то это не значит, что не назрели тенденции. Язык C++ сделал когда прорыв в мэйнстриме, многому нас научил, многое сделал. Но теперь он уже отжил своё.

Аналогия: человеческий организм перестает расти к 23-27 годам, после чего начинаются необратимые обратные процессы, затягивающиеся у некоторых индивидов на 50 и более лет. Однако, мало кому приходит в голову обзывать живых людей, находящихся в зрелом возрасте, "трупами" просто на основании того, что их биологическое развитие завершено.

Теперь ближе к теме. Никто, вдумайтесь, никто не в стостоянии вообразить себе степень проникновения C++ в современный IT. Об этом неоднократно говорил Страуструп, а уж кому как не ему интересоваться судьбой языка и выслушивать пожелания от разных групп пользователей. Изъять C++ из современных систем невозможно, переписать все C++ программы на что-то другое -- невозможно. Просто представте себе: н-е-в-о-з-м-о-ж-н-о!

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